but I'm curious as to why PHP is so popular when JSP provides a much more robust solution
PHP is not a one-fits-all type of solution. It does not provide the same infrastructure that Java solutions do, and it is not a pure OO language. However, there are some good reasons to use it, depending on your situation:
[1] Easier to learn than Java
[2] Simpler to setup than many Java solutions
[3] A great selection of extremely useful, easily accessible, built-in functions
[4] Wide selection of books that don't assume you're already an experienced engineer
The creators of PHP went to great lengths to remove as many of the needless annoyances of web development as possible. They provide a lot of ready made solutions to small, but annoying common problems. The language has bent itself to developer needs, rather than the other way around.
PHP's creators realize that people just want the damn thing work, which is even evident in the installation instructions and documentation. This philopsophy, while starlingly rare in the open source world, is probably at the core of why PHP has such a devoted following.
The strip_tags function is probably a good example of this. You give it a text string and it will remove all HTML tags contained therein. That's it. You can optionally tell it specific tags that you would like to leave in. This function is built into the language. PHP users love this. Many other languages would expect you to write a custom regex routine or go find some code somewhere to take care of it. Or you can start playing the module dependency game. These isn't the kind of stuff I want to do at 2am.
What is the advantage of doing a servlet? Just to be programming in Java?
A server-side Java application is called a servlet. It has no special status that I'm aware of.
So what does Tomcat have to do with this?
Tomcat provides you with a means to use servlets and JSP on your web site.
If I write in Java and compile it to a host machine executeable binary format instead of a class file, and run it under the CGI mechanism, would it still be called a servlet?
No, I don't believe so. I think they are only refered to as servlets if they exist as Java bytecode. But I'm not sure why you'd want to do what you describe here.:)
So why can't I just compile my code after I write it, and run it that way?
You can.
And why do I have to mix code and content?
This is a difficult question. You don't have to mix code and content. In fact you want to do so as little as possible. Here's what it comes down to:
Many large scale web sites are a combination of front end UI written in HTML/CSS and backend database-driven functionality written in Java. Somehow you need to dynamically generate HTML based on database content and given critera. People figured out pretty fast that most web pages are sufficiently complex that embedding HTML/CSS directly in Java code (or a Perl/CGI script) is not a good solution. It makes the Java code difficult to read for the programmer, and it makes it very difficult for the designer to change the appearance of the site.
Things like JSP and PHP attempt to head towards solving this. Rather than having all the HTML and Java code in one massive file, you have more template-like functionality. You initially create a HTML page as your template, then add dynamic elements using the scripting language. With JSP, the bulk of functionality is theoretically stored in other places, like JavaBeans. You then call this functionality with custom tags.
This is not enforced, however. PHP and JSP are quite rich languages. If you design or maintain your JSP/PHP application poorly, you might find yourself back at square one: too much mixing of code and content. Except this time, too much code has creeped into the content, rather than the content creeping into the code. I must emphasize that it doesn't have to be this way. At least in the context of PHP, proper use of includes and objects should solve most major problems. But not everybody is that careful.
Another (some would say more evolved) approach are the pure template languages like Velocity (for Java) and Smarty (for PHP). They do not have the rich language structure of raw PHP or JSP. They only provide the most basic ways to output data. They force you to put complex logic somewhere other than the HTML template.
For the most demanding enterprise-class applications, you will need a full scale application server with load balancing, enterprise frameworks, and other high-end featurees. One such app server is WebObjects. There are many others.
You're talking about some good things, but I'm still looking for why Tomcat is the only, or best, way to have this.
It's definitely not the only one, and the best is certainly a matter of what you're trying to accomplish. There are a lot of options out there, and it's understandable that you might be a little overwhelmed.
The first thing to do is determine what your needs are. A lot of people like PHP, and with good reason. It's fast, it's easy to learn, has a lot of very useful built-in functionality, and is open source. PHP can also interface with Java. However, it can be argued that PHP cannot provide the infrastructure and scalability that a pure Java solution can.
If you decided to use Java, you have a mind-boggling number of options open to you. The options range from free/open source to very expensive. You have servlets, JSP, Velocity, Cocoon, XML, application servers and much more. Java has hooks into just about every aspect of server-side application development right now. To choose one as the best is impossible. It might make things to think of Java as the platform for all of these things.
Tomcat, specifially, is a servlet/JSP engine. There are dozens of other such pieces of software. Tomcat tends to get more visibility because it is under the Apache banner.
So when deciding what to use depends on these varibles, in addition to others:
[1] Your timeline to complete your project
[2] Your existing programming knowledge
[3] Your budget/human resources
[4] Sophistication of the site/application you need to build
[5] Personal taste
There is no one perfect solution for everyone, but some are more popular than others. In your case, you probably want to choose something with broad community support and lots of free documentation, sample code, third party books, etc. In my personal opinion, if you're just getting started with web development, and have absolutely no idea what you want, try PHP. It will probably get you up and running the quickest. It also has a tendency to teach you web development concepts without you realizing it.
If you want to get more involved in web development as a career, you might also want to get a book that teaches you the Java language (ideally, with a focus on servlets). After that, you might have a clearer idea of what to tackle next.
You don't need them per say. But a lot server-side applications are written as servlets.
And is Java the only way to do servlets?
Yes, but I don't think that really answers the question you're asking. A "servlet" is just the affectionate term for a server-side Java application. "Servlet" implies Java the same way "applet" does.
Why not servlets in say, C or Perl or TCL or Lisp or whatever?
You can write server-side applications in any of these languages, they're just not called servlets.
The cheapest G4, with the lowest clock speed, is $1700. Bump up the clock speed a bit and we're at $2500.
The additional $800 gets you quite a bit more than a faster CPU. You get a DVD-R drive, which is -- what -- $1000 on its own? You also get a 2MB L3 cache and a bigger hard drive. And all Macs have gigabit ethernet, wireless antenneas, and firewire. The PowerMacs also have cases that meet or beat anything else in the industry in terms of convenience.
That's _crazy_, considering that you can get a roughly equivalent Pentium III or Athlon system for under $800. (The G4 is a better CPU than the Pentium III or Athlon, but not _that_ much better, and the better memory systems on the PC balance out the difference in most cases.)
I won't even get into the MHz issue, but why do people feel that the CPU is only way to assess value in a computer? That's just one factor, and an increasingly irrelevant one. The top two PowerMacs come with DVD-R drives, for example. And the $3500 one is a dual 800. Look at the *whole* computer. You can have a great CPU and memory system and still have a shitty computer.
What's needed here is an explanation of Apple's business model.
Unlike a huge majority of bare bones wintel manufactuers, Apple actually develops unique products and a separate platform, which means we're dangerously close to having real mainstream choice in computing (based on a unix-like core, no less!). But developing these products, creating a mainstream platform, and providing all sorts of free software and internet services (banner-free) to users costs money.
Last quarter, Apple brought in gross revenues of $1.475 billion. Their gross margins were 30%. But they only reported a $61 million profit. Where does all the money go? Back into the products. They can afford to do this because they have $4 billion in the bank. They are building up for the long term.
Most companies that will sell you a cheap workstation are working on razor thin margins. That's great in the short term if you're buying a machine. But it also means very little product development is happening. It's just a numbers game. How different are all the wintel PCs really? Hundreds of manufactures all using the same basic components and same OS does not provide choice. They're almost identitical in terms of the end result.
Selling lots of machines at razor thin margins does not necessarily put you in a good position. You just need to look at tech news from the last four months to see that. Thousands of layoffs, mergers, outright bankruptcy. Meanwhile, Apple has sustained its business, and has had laid off a total about 50 people this summer. Of course, things have changed recently, so Apple may encounter difficulties. But selling cheap boxes is in no way a guarantees for your business.
A box as good as apples Network Server Line [ac-scanmac.dk] but, rack mountable.
Hot swap HDs, Fans, Power Suplies, and PCI cards.
I think it would be really cool if they did this, but I'm not entirely convinced the market is there for Apple-branded, rack mounted, hot swappable hardware. I'd sure like there to be.
Thats all i can think of off the top of my head, but i think this is the direction they need to go. If they release a server box with 4 cpus, rack mount, everything hot swapable, built in RAID, etc, etc, sign me up for 4 =)
So here's the question. If Apple were to make something like this, it would cost more than the Dell equivalent (Apple has more product development and platform management costs). What do you think would make you/other people buy this over a Dell, or any similar wintel manufacturer? The UI? The ease of administration? Or is it the idea of having a kickass desktop platform, and you'd like a server component?
It has a G5, LCD, kick-ass design, OS X, etc etc. Can you image the waves such a product would make? Make the screen 17" and throw in a GeForce3 GPU, and I'll but 10:)
You can get all of this (sans the G5) today. Just buy a PowerMac instead of an iMac. You can't expect a top-of-the-line processor, top-of-the-line NVIDIA card and 17" LCD in the $799-$1500 iMac price range.
A good 17" LCD alone would run you $800-$1000. Apple simply does not skip when it comes to display quality. They're all about the visuals.
However, Nintendo has a poor track record [everything2.com] with respect to the general bugginess of the details of the Mario Kart play design in 1 and 2
These issues listed at that URL are rather minor that really don't seem affect the overall experience.
I mean, according to the author of that article, some of the alleged "bugs" in the first Mario Kart are "Starman lasts too long," "Ghost powerup lasts way too long," and my personal favorite, "No in-car camera view." I'd be curious as to how this would be implemented in an accurate way on a Super Nintendo with only mode 7 at your disposal.
These aren't bugs, these are things the author personally doesn't like. In other words, stop player hatin'.
I've posted similar messages in this topic, but wanted to get it up to a higher level to resolve a lot of the confusion...
Even in a finished state, GNUStep does not do as much to get apps to Linux as some people seem to think Or, at least, not the apps they have in mind. If you're at all familiar with Mac OS X development, you know that there are four APIs that the system considers "native": Cocoa, Carbon, Java and BSD. Any program written to these APIs receives it own 2GB of protected address space (yes, even individual Java apps), as well other modern OS features. Classic is the Mac OS 9/8 compatibility environment. Sort of an "emulator on steroids," to use a cliche.
GNUStep provides a implementation of the OpenStep spec, which is what Cocoa is based on. Theoretically, this means that Mac OS X apps written in Cocoa can be easily ported. But the vast majority of the brand name apps have been or are being ported to Mac OS X are written in Carbon. The long list of Carbon apps includes:
Quite a few people have posted messages to this topic mistakeningly claiming some Carbon apps were actually Cocoa apps, including Office. I'm not sure what would have caused this confusion. Part of the problem may be that you cannot tell the difference between a Cocoa app and and a Carbon app unless you really know what to look for. Both use Aqua UI widgets. Some individuals might also be making the assumption that if an app is "Mac OS X only" (meaning does not run on Mac OS 9), then it must be written in Cocoa, which is not true.
So why write in Carbon, you ask?
Most existing Mac developers port apps to Carbon because it's easier than a complete rewrite in Cocoa. It also means that developers can keep reasonably similar (in some cases, identical) code bases for both Mac OS X and Mac OS 9. This is important because most of their customers will be on Mac OS 9 until the transition is complete. Alias|Wavefront was not porting an existing Mac app, but opted to use Carbon for Maya because they have existing C++ code (and developers?) they want to use. Cocoa frameworks can currently only be accessed from Objective-C or Java.
Over time, you may see developers do rewrites in Cocoa, because in many ways it is a better environment. Ther resurrection of Objective-C++ would probably help this. But the more Apple does to improve and refine Carbon, the less immediate the need will be to do rewrites in Cocoa.
So that's that. Now, getting back to GNUStep....
From this interview, it sounds like the GNUStep folks have the Foundation side of Cocoa pretty well in hand, but it looks like AppKit (all of the GUI stuff) is not done. But even after they finish everything that has been around since OpenStep, I'm curious how they're going to resolve all sorts of new stuff. Specifically, I'm thinking about things like QuickTime (used for much more than video), Quartz (transparency/compositing, PDF generation/manipulation, text rendering), and even stuff like AppleScript/Apple Events. These are things that Mac OS X developers are and will be using, but I can't imagine they're going to be very easily to implement from scratch on the GNUStep side. I understand that there are perhaps counterparts, but how comparable will they be? I'm genuinely curious about this.
I praise Adam and his colleagues for their efforts. But at the same time,/.ers shouldn't let their expectations get out of hand. At the moment, GNUStep is no more helpful in getting MS Office to Linux than is Mac OS X's use of BSD libraries.
There are actually quite a few brand name apps that have been ported to Mac OS X, and many more are in progress. Probably more than people outside the Mac community would guess. Corel is on the ball -- Bryce and Painter are ported, Microsoft has already released Explorer and Office 10 is almost ready. Macromedia already has Freehand out, and both it and Adobe are working furiously to port everything. Other stuff that's done: Quicken, Maya, quite a few games, and tons of other stuff that I'm forgetting.
These have all been ported to Mac OS X APIs. The problem is (for GNUStep users, anyway), these apps use the Carbon APIs, not Cocoa. Cocoa is GNUStep's counterpart.
There aren't many at the moment, beacause they really became finalized in march, but there are some things like FileMaker Pro that are completely cocoa, and work impressively well. Oh, and Maya is completely Cocoa.
This is the fifth post or so that has named Carbon apps, and claimed they were written in Cocoa. I wish I knew what the source of misinformation was.
I have repeatedly been told from people that should know (Maya fanatics) that Maya is definitely a Carbon app. This was done because they needed to use C++ frameworks (Cocoa is currently ObjC and Java only). I don't know about FileMaker, but I would be pretty surprised if it was Cocoa. Who told you these were Cocoa apps?
Perhaps if you look at it in terms of only Mach/BSD and Cocoa. There is tons of stuff there that was never in NeXT, though: Carbon, Quartz, system-level QuickTime usage, AppleScript/AppleEvents, I/O Kit, Mac OS 9 compatibility.
It borrows some lower-level from NextStep, some higher level stuff from Mac OS, and makes something brand new. GNUStep apparently only attempts to address the NeXT side of the world, but a lot of the mainstream items will make heavy use of the Mac side of things.
On the near horizon, Adobe Illustrator 10 and Quark 5 are nearing release (both demonstrated at MWNY in July) and they are both, to the best of my knowledge, Cocoa native. [...] Office for OSX will also be Cocoa native
I'm not sure who has given you this indication. Office 10 is most definitely a Carbon app. You can have Carbon apps that only run on Mac OS X and not Mac OS 9. Office 10 is one such app. Is this the source of the confusion?
Unfortunately, you're not looking towards the future: Adobe, Microsoft, and several other major software manufacturers have promised versions of their major titles for the Cocoa API, several of which have been demonstrated live in the last few months. I encourage you to look at both Microsoft's Macintosh pages, as well as Adobe's web site.
I'm not sure what you'd be referring to. The products that Microsoft has announced for Mac OS X -- Office 10 (for Mac OS X only, not Mac OS 9/8) and Explorer -- are both Carbon apps. They have not demoed or confirmed any Cocoa apps in the works. They may eventually, but it's debatable if there is reason to do so anytime soon if Apple continues to improve Carbon. The story is pretty much the same on Adobe's side. They have demoed InDesign, Illustrator, GoLive and some others. They have also release a native version of Acrobat. But these are all Carbon apps. They have not talked about any Cocoa apps.
Aside from the fact that it is generally easier to port existing large Mac apps to Carbon than rewrite them in Cocoa, Micrsoft and Adobe still have the vast majority of their customers on Mac OS 9/8. They are probably not too keen to do massive forks at this point. The fact that the Mac OS Toolbox and Carbon APIs are similar makes it fiscally feasible to address both Mac OS 9 and Mac OS X markets.
There are two ways to use Carbon. You can create a single Carbon binary that executes on both Mac OS 9/8 (old technology) and Mac OS X (Mach/BSD). However, this somewhat limits how much you can do on the Mac OS X side. The other option is to use Carbon only as a porting bridge. You don't end up with two separate binaries (one for OS9, one for OSX), but you still get two relatively similar code bases with similar API calls. This is what many developers have opted to do since it allows them to build a better Mac OS X app without having to completely rewrite their software. Microsoft is currently doing this with Explorer.
There actually is a third reason to use Carbon -- it's a C/C++ framework. Maya opted to use Carbon for this reason. Cocoa apps can currently only be written in Objective-C and Java. There is talk about resurrecting Objective-C++, though.
Carbon and Cocoa apps can look essentially identical to the untrained eye. Both make calls to the same core frameworks. They both provide protected memory spaces, preemptive multitasking, and access to Quartz. They are peers in many ways. "Classic" is the compatibility environment in which a Mac OS 9 virtual machine is launched to run old Mac apps that have not been ported to either of the new APIs. While Cocoa and Classic apps use Aqua UI widgets, Classic apps do not. They generally have the grey chizeled look of Mac OS 9.
By the way -- the Finder, Mac OS X's file manager/shell is written in Carbon, as is the event manager. And based on Apple's statements, it looks like they have done a lot of work on Carbon for the emminent Mac OS X 10.1 release. Several upcoming Carbon Mac OS X apps require 10.1.
I would like to know if there are any IP issues the GNUStep have had, or will have to deal with?
It is legal for them to write implementations of the OpenStep/Cocoa APIs. But there are going to be walls. No Quartz or QuickTime, for example. These are considered core components of Mac OS X.
6000 die every DAY in this country. And 100,000 humans die every die on this planet.
Quantity is not the only issue. It's the fact that the deaths were so sudden, in such a small area, and the result of malicious intent. These people were executed. Many of the deaths you're talking about are due to age, disease, and some that have voluntairly entered themselves into conflict. At least some have time to prepare, make sure their families are taken care of. The people in the world trade center were doing paperwork when a 757 flew into the building.
Hell if you wanted to mirror all the linux distro's you could do it with rsync.
So use Linux.
doesn't have big bandwidth friends willing to mirror it for free
That really has nothing to do with it. Apple doesn't distribute software through third parties. This isn't just another *nix distribution. If you want to mirror something, mirror Darwin. It's a perfectly capable *nix OS.
because Apple doesn't give a damn thing back to the community from which it stole its code from
Oh, please. Everything they "stole" (and modified) is re-released to the community as a complete OS in Darwin. They've introduced a lot of new code to the community -- NetInfo, OpenPlay, NetSprocket, QuickTime Streaming Server, and CDSA. They've also submitted patches back to the BSDs and Apache.
care to back that up with some fact? there are ALOT of Solaris boxes out there.
Apple did $19 million in sales of Mac OS X the first weekend it was out. Assuming everyone in that number paid the full $129 price, you get about 150,000 right out of the gate. This doesn't take into account all the beta testers (100,000 in all) that got a $30 discount. Then you tally the developers, educators, and Apple specialists that get it for substanially less or free outright (this revenue might not even been counted in the $19m since it's through special channels).
Then add in that every machine Apple ships now comes with Mac OS X, and that they shipped 827,000 machines last quarter (which ended June 30). And they've certainly sold some copies of OS X off the shelf in the last 5 months. And none of that counts burned copies of Mac OS X or Darwin users.
I suspect it's a relatively big number, probably over 1 million at this point. I'm guessing that it will be at least 2 million year's end. And note that all of this happens despite the fact Apple has run zero TV or magazine advertisements for Mac OS X at this point. They are certainly holding off on marketing campaign until at least until 10.1, and very likely until Office 10 comes out (sometime this fall). I'm not clear on whether the measurement for largest Unix vendor is the number of units sold in a particular period of time (which I suspect Apple is kicking ass on), or the total installed base.
"Apple negotiated a deal with Xerox; in return for a block of Apple stock, Xerox allowed Jobs and his team to tour PARC, take notes, and implement some of the ideas and concepts being bounced around at PARC in their own creations."
Pirates seriously messed with history in this regard, having never touched on the deal Jobs made with Xerox, and the made-up commentary by the "Wozniak" character.
But on the downside, the author doesn't spell Jef Raskin correctly.
Heh, yeah, companies like MS have had a real tough go of it trying to turn a profit on an OS for x86 hardware.
Who else besides MS is making money doing it? The reason there's no money in it (other than for MS) is because of MS.
And OS X is derived from OPENSTEP, which already ran on x86 hardware. Darwin has an x86 build, and there are persistent rumors of an internal x86 OS X build at Apple.
I'm sure Apple could get OSX running on x86, and probably has. The hurdles I was referring to weren't technical in nature, but rather things like "who would buy this and use it at the exclusivity of Windows?" Many developers won't bothering port apps if users can already run Windows on the same machine -- they'll just buy the Windows software.
The only real hurdle is getting Apple to stop thinking of themselves as a hardware company and start marketing their software as a separate product.
From a financial perspective, Apple is a hardware company. From a product development perspective, Apple is neither hardware nor software company -- it is both. The hardware and software have a symbiotic relationship. The hardware helps sell the software and vice-versa. Separate one from the other, and you lose a lot of the value.
Never developed on a NeXT system, I see. The "porting" cost was essentially the time it took to go into ProjectBuilder and click the checkbox for the desired platform.
Office and IE aren't written in Cocoa, and they actually use CodeWarrior for IE, not PB. I'm guessing it's the same for Office. But I wasn't talking about the development time. I meant they wouldn't release such a product for business reasons. OSX for x86 would be in direct competition with them -- they wouldn't support it.
Slashdot Mirror
Three words: Model - View - Control
Which is the concept Velocity is built around, correct?
- Scott
but I'm curious as to why PHP is so popular when JSP provides a much more robust solution
PHP is not a one-fits-all type of solution. It does not provide the same infrastructure that Java solutions do, and it is not a pure OO language. However, there are some good reasons to use it, depending on your situation:
[1] Easier to learn than Java
[2] Simpler to setup than many Java solutions
[3] A great selection of extremely useful, easily accessible, built-in functions
[4] Wide selection of books that don't assume you're already an experienced engineer
The creators of PHP went to great lengths to remove as many of the needless annoyances of web development as possible. They provide a lot of ready made solutions to small, but annoying common problems. The language has bent itself to developer needs, rather than the other way around.
PHP's creators realize that people just want the damn thing work, which is even evident in the installation instructions and documentation. This philopsophy, while starlingly rare in the open source world, is probably at the core of why PHP has such a devoted following.
The strip_tags function is probably a good example of this. You give it a text string and it will remove all HTML tags contained therein. That's it. You can optionally tell it specific tags that you would like to leave in. This function is built into the language. PHP users love this. Many other languages would expect you to write a custom regex routine or go find some code somewhere to take care of it. Or you can start playing the module dependency game. These isn't the kind of stuff I want to do at 2am.
- Scott
What is the advantage of doing a servlet? Just to be programming in Java?
:)
A server-side Java application is called a servlet. It has no special status that I'm aware of.
So what does Tomcat have to do with this?
Tomcat provides you with a means to use servlets and JSP on your web site.
If I write in Java and compile it to a host machine executeable binary format instead of a class file, and run it under the CGI mechanism, would it still be called a servlet?
No, I don't believe so. I think they are only refered to as servlets if they exist as Java bytecode. But I'm not sure why you'd want to do what you describe here.
- Scott
So why can't I just compile my code after I write it, and run it that way?
You can.
And why do I have to mix code and content?
This is a difficult question. You don't have to mix code and content. In fact you want to do so as little as possible. Here's what it comes down to:
Many large scale web sites are a combination of front end UI written in HTML/CSS and backend database-driven functionality written in Java. Somehow you need to dynamically generate HTML based on database content and given critera. People figured out pretty fast that most web pages are sufficiently complex that embedding HTML/CSS directly in Java code (or a Perl/CGI script) is not a good solution. It makes the Java code difficult to read for the programmer, and it makes it very difficult for the designer to change the appearance of the site.
Things like JSP and PHP attempt to head towards solving this. Rather than having all the HTML and Java code in one massive file, you have more template-like functionality. You initially create a HTML page as your template, then add dynamic elements using the scripting language. With JSP, the bulk of functionality is theoretically stored in other places, like JavaBeans. You then call this functionality with custom tags.
This is not enforced, however. PHP and JSP are quite rich languages. If you design or maintain your JSP/PHP application poorly, you might find yourself back at square one: too much mixing of code and content. Except this time, too much code has creeped into the content, rather than the content creeping into the code. I must emphasize that it doesn't have to be this way. At least in the context of PHP, proper use of includes and objects should solve most major problems. But not everybody is that careful.
Another (some would say more evolved) approach are the pure template languages like Velocity (for Java) and Smarty (for PHP). They do not have the rich language structure of raw PHP or JSP. They only provide the most basic ways to output data. They force you to put complex logic somewhere other than the HTML template.
For the most demanding enterprise-class applications, you will need a full scale application server with load balancing, enterprise frameworks, and other high-end featurees. One such app server is WebObjects. There are many others.
You're talking about some good things, but I'm still looking for why Tomcat is the only, or best, way to have this.
It's definitely not the only one, and the best is certainly a matter of what you're trying to accomplish. There are a lot of options out there, and it's understandable that you might be a little overwhelmed.
The first thing to do is determine what your needs are. A lot of people like PHP, and with good reason. It's fast, it's easy to learn, has a lot of very useful built-in functionality, and is open source. PHP can also interface with Java. However, it can be argued that PHP cannot provide the infrastructure and scalability that a pure Java solution can.
If you decided to use Java, you have a mind-boggling number of options open to you. The options range from free/open source to very expensive. You have servlets, JSP, Velocity, Cocoon, XML, application servers and much more. Java has hooks into just about every aspect of server-side application development right now. To choose one as the best is impossible. It might make things to think of Java as the platform for all of these things.
Tomcat, specifially, is a servlet/JSP engine. There are dozens of other such pieces of software. Tomcat tends to get more visibility because it is under the Apache banner.
So when deciding what to use depends on these varibles, in addition to others:
[1] Your timeline to complete your project
[2] Your existing programming knowledge
[3] Your budget/human resources
[4] Sophistication of the site/application you need to build
[5] Personal taste
There is no one perfect solution for everyone, but some are more popular than others. In your case, you probably want to choose something with broad community support and lots of free documentation, sample code, third party books, etc. In my personal opinion, if you're just getting started with web development, and have absolutely no idea what you want, try PHP. It will probably get you up and running the quickest. It also has a tendency to teach you web development concepts without you realizing it.
If you want to get more involved in web development as a career, you might also want to get a book that teaches you the Java language (ideally, with a focus on servlets). After that, you might have a clearer idea of what to tackle next.
- Scott
And why do I need servlets?
You don't need them per say. But a lot server-side applications are written as servlets.
And is Java the only way to do servlets?
Yes, but I don't think that really answers the question you're asking. A "servlet" is just the affectionate term for a server-side Java application. "Servlet" implies Java the same way "applet" does.
Why not servlets in say, C or Perl or TCL or Lisp or whatever?
You can write server-side applications in any of these languages, they're just not called servlets.
- Scott
The cheapest G4, with the lowest clock speed, is $1700. Bump up the clock speed a bit and we're at $2500.
The additional $800 gets you quite a bit more than a faster CPU. You get a DVD-R drive, which is -- what -- $1000 on its own? You also get a 2MB L3 cache and a bigger hard drive. And all Macs have gigabit ethernet, wireless antenneas, and firewire. The PowerMacs also have cases that meet or beat anything else in the industry in terms of convenience.
That's _crazy_, considering that you can get a roughly equivalent Pentium III or Athlon system for under $800. (The G4 is a better CPU than the Pentium III or Athlon, but not _that_ much better, and the better memory systems on the PC balance out the difference in most cases.)
I won't even get into the MHz issue, but why do people feel that the CPU is only way to assess value in a computer? That's just one factor, and an increasingly irrelevant one. The top two PowerMacs come with DVD-R drives, for example. And the $3500 one is a dual 800. Look at the *whole* computer. You can have a great CPU and memory system and still have a shitty computer.
What's needed here is an explanation of Apple's business model.
Unlike a huge majority of bare bones wintel manufactuers, Apple actually develops unique products and a separate platform, which means we're dangerously close to having real mainstream choice in computing (based on a unix-like core, no less!). But developing these products, creating a mainstream platform, and providing all sorts of free software and internet services (banner-free) to users costs money.
Last quarter, Apple brought in gross revenues of $1.475 billion. Their gross margins were 30%. But they only reported a $61 million profit. Where does all the money go? Back into the products. They can afford to do this because they have $4 billion in the bank. They are building up for the long term.
Most companies that will sell you a cheap workstation are working on razor thin margins. That's great in the short term if you're buying a machine. But it also means very little product development is happening. It's just a numbers game. How different are all the wintel PCs really? Hundreds of manufactures all using the same basic components and same OS does not provide choice. They're almost identitical in terms of the end result.
Selling lots of machines at razor thin margins does not necessarily put you in a good position. You just need to look at tech news from the last four months to see that. Thousands of layoffs, mergers, outright bankruptcy. Meanwhile, Apple has sustained its business, and has had laid off a total about 50 people this summer. Of course, things have changed recently, so Apple may encounter difficulties. But selling cheap boxes is in no way a guarantees for your business.
- Scott
should run the only two killer apps available for Mac, Photoshop and Eudora
I think a lot of people consider Final Cut and iMovie/iDVD to be pretty special... just off the top of my head. And you still have direct BSD access.
- Scott
A box as good as apples Network Server Line [ac-scanmac.dk] but, rack mountable.
Hot swap HDs, Fans, Power Suplies, and PCI cards.
I think it would be really cool if they did this, but I'm not entirely convinced the market is there for Apple-branded, rack mounted, hot swappable hardware. I'd sure like there to be.
Thats all i can think of off the top of my head, but i think this is the direction they need to go. If they release a server box with 4 cpus, rack mount, everything hot swapable, built in RAID, etc, etc, sign me up for 4 =)
So here's the question. If Apple were to make something like this, it would cost more than the Dell equivalent (Apple has more product development and platform management costs). What do you think would make you/other people buy this over a Dell, or any similar wintel manufacturer? The UI? The ease of administration? Or is it the idea of having a kickass desktop platform, and you'd like a server component?
Just curious... following the logic out.
- Scott
It has a G5, LCD, kick-ass design, OS X, etc etc. Can you image the waves such a product would make? Make the screen 17" and throw in a GeForce3 GPU, and I'll but 10 :)
You can get all of this (sans the G5) today. Just buy a PowerMac instead of an iMac. You can't expect a top-of-the-line processor, top-of-the-line NVIDIA card and 17" LCD in the $799-$1500 iMac price range.
A good 17" LCD alone would run you $800-$1000. Apple simply does not skip when it comes to display quality. They're all about the visuals.
- Scott
However, Nintendo has a poor track record [everything2.com] with respect to the general bugginess of the details of the Mario Kart play design in 1 and 2
These issues listed at that URL are rather minor that really don't seem affect the overall experience.
I mean, according to the author of that article, some of the alleged "bugs" in the first Mario Kart are "Starman lasts too long," "Ghost powerup lasts way too long," and my personal favorite, "No in-car camera view." I'd be curious as to how this would be implemented in an accurate way on a Super Nintendo with only mode 7 at your disposal.
These aren't bugs, these are things the author personally doesn't like. In other words, stop player hatin'.
- Scott
I've posted similar messages in this topic, but wanted to get it up to a higher level to resolve a lot of the confusion...
/.ers shouldn't let their expectations get out of hand. At the moment, GNUStep is no more helpful in getting MS Office to Linux than is Mac OS X's use of BSD libraries.
Even in a finished state, GNUStep does not do as much to get apps to Linux as some people seem to think Or, at least, not the apps they have in mind. If you're at all familiar with Mac OS X development, you know that there are four APIs that the system considers "native": Cocoa, Carbon, Java and BSD. Any program written to these APIs receives it own 2GB of protected address space (yes, even individual Java apps), as well other modern OS features. Classic is the Mac OS 9/8 compatibility environment. Sort of an "emulator on steroids," to use a cliche.
GNUStep provides a implementation of the OpenStep spec, which is what Cocoa is based on. Theoretically, this means that Mac OS X apps written in Cocoa can be easily ported. But the vast majority of the brand name apps have been or are being ported to Mac OS X are written in Carbon. The long list of Carbon apps includes:
- Office
- Explorer
- Macromedia Freehand
- Acrobat
- GoLive
- Illustrator
- Bryce
- Corel Knockout
- Corel Draw
- Painter (Corel/MetaCreation)
- Maya
- Quicken
- Netscape
Quite a few people have posted messages to this topic mistakeningly claiming some Carbon apps were actually Cocoa apps, including Office. I'm not sure what would have caused this confusion. Part of the problem may be that you cannot tell the difference between a Cocoa app and and a Carbon app unless you really know what to look for. Both use Aqua UI widgets. Some individuals might also be making the assumption that if an app is "Mac OS X only" (meaning does not run on Mac OS 9), then it must be written in Cocoa, which is not true.
So why write in Carbon, you ask?
Most existing Mac developers port apps to Carbon because it's easier than a complete rewrite in Cocoa. It also means that developers can keep reasonably similar (in some cases, identical) code bases for both Mac OS X and Mac OS 9. This is important because most of their customers will be on Mac OS 9 until the transition is complete. Alias|Wavefront was not porting an existing Mac app, but opted to use Carbon for Maya because they have existing C++ code (and developers?) they want to use. Cocoa frameworks can currently only be accessed from Objective-C or Java.
Over time, you may see developers do rewrites in Cocoa, because in many ways it is a better environment. Ther resurrection of Objective-C++ would probably help this. But the more Apple does to improve and refine Carbon, the less immediate the need will be to do rewrites in Cocoa.
So that's that. Now, getting back to GNUStep....
From this interview, it sounds like the GNUStep folks have the Foundation side of Cocoa pretty well in hand, but it looks like AppKit (all of the GUI stuff) is not done. But even after they finish everything that has been around since OpenStep, I'm curious how they're going to resolve all sorts of new stuff. Specifically, I'm thinking about things like QuickTime (used for much more than video), Quartz (transparency/compositing, PDF generation/manipulation, text rendering), and even stuff like AppleScript/Apple Events. These are things that Mac OS X developers are and will be using, but I can't imagine they're going to be very easily to implement from scratch on the GNUStep side. I understand that there are perhaps counterparts, but how comparable will they be? I'm genuinely curious about this.
I praise Adam and his colleagues for their efforts. But at the same time,
- Scott
There's hardly any apps that use the OS X APIs
There are actually quite a few brand name apps that have been ported to Mac OS X, and many more are in progress. Probably more than people outside the Mac community would guess. Corel is on the ball -- Bryce and Painter are ported, Microsoft has already released Explorer and Office 10 is almost ready. Macromedia already has Freehand out, and both it and Adobe are working furiously to port everything. Other stuff that's done: Quicken, Maya, quite a few games, and tons of other stuff that I'm forgetting.
These have all been ported to Mac OS X APIs. The problem is (for GNUStep users, anyway), these apps use the Carbon APIs, not Cocoa. Cocoa is GNUStep's counterpart.
- Scott
There aren't many at the moment, beacause they really became finalized in march, but there are some things like FileMaker Pro that are completely cocoa, and work impressively well. Oh, and Maya is completely Cocoa.
This is the fifth post or so that has named Carbon apps, and claimed they were written in Cocoa. I wish I knew what the source of misinformation was.
I have repeatedly been told from people that should know (Maya fanatics) that Maya is definitely a Carbon app. This was done because they needed to use C++ frameworks (Cocoa is currently ObjC and Java only). I don't know about FileMaker, but I would be pretty surprised if it was Cocoa. Who told you these were Cocoa apps?
- Scott
Remember, Mac OS X is essentially NeXTSTEP
Perhaps if you look at it in terms of only Mach/BSD and Cocoa. There is tons of stuff there that was never in NeXT, though: Carbon, Quartz, system-level QuickTime usage, AppleScript/AppleEvents, I/O Kit, Mac OS 9 compatibility.
It borrows some lower-level from NextStep, some higher level stuff from Mac OS, and makes something brand new. GNUStep apparently only attempts to address the NeXT side of the world, but a lot of the mainstream items will make heavy use of the Mac side of things.
- Scott
On the near horizon, Adobe Illustrator 10 and Quark 5 are nearing release (both demonstrated at MWNY in July) and they are both, to the best of my knowledge, Cocoa native. [...] Office for OSX will also be Cocoa native
I'm not sure who has given you this indication. Office 10 is most definitely a Carbon app. You can have Carbon apps that only run on Mac OS X and not Mac OS 9. Office 10 is one such app. Is this the source of the confusion?
- Scott
Unfortunately, you're not looking towards the future: Adobe, Microsoft, and several other major software manufacturers have promised versions of their major titles for the Cocoa API, several of which have been demonstrated live in the last few months. I encourage you to look at both Microsoft's Macintosh pages, as well as Adobe's web site.
I'm not sure what you'd be referring to. The products that Microsoft has announced for Mac OS X -- Office 10 (for Mac OS X only, not Mac OS 9/8) and Explorer -- are both Carbon apps. They have not demoed or confirmed any Cocoa apps in the works. They may eventually, but it's debatable if there is reason to do so anytime soon if Apple continues to improve Carbon. The story is pretty much the same on Adobe's side. They have demoed InDesign, Illustrator, GoLive and some others. They have also release a native version of Acrobat. But these are all Carbon apps. They have not talked about any Cocoa apps.
Aside from the fact that it is generally easier to port existing large Mac apps to Carbon than rewrite them in Cocoa, Micrsoft and Adobe still have the vast majority of their customers on Mac OS 9/8. They are probably not too keen to do massive forks at this point. The fact that the Mac OS Toolbox and Carbon APIs are similar makes it fiscally feasible to address both Mac OS 9 and Mac OS X markets.
There are two ways to use Carbon. You can create a single Carbon binary that executes on both Mac OS 9/8 (old technology) and Mac OS X (Mach/BSD). However, this somewhat limits how much you can do on the Mac OS X side. The other option is to use Carbon only as a porting bridge. You don't end up with two separate binaries (one for OS9, one for OSX), but you still get two relatively similar code bases with similar API calls. This is what many developers have opted to do since it allows them to build a better Mac OS X app without having to completely rewrite their software. Microsoft is currently doing this with Explorer.
There actually is a third reason to use Carbon -- it's a C/C++ framework. Maya opted to use Carbon for this reason. Cocoa apps can currently only be written in Objective-C and Java. There is talk about resurrecting Objective-C++, though.
Carbon and Cocoa apps can look essentially identical to the untrained eye. Both make calls to the same core frameworks. They both provide protected memory spaces, preemptive multitasking, and access to Quartz. They are peers in many ways. "Classic" is the compatibility environment in which a Mac OS 9 virtual machine is launched to run old Mac apps that have not been ported to either of the new APIs. While Cocoa and Classic apps use Aqua UI widgets, Classic apps do not. They generally have the grey chizeled look of Mac OS 9.
By the way -- the Finder, Mac OS X's file manager/shell is written in Carbon, as is the event manager. And based on Apple's statements, it looks like they have done a lot of work on Carbon for the emminent Mac OS X 10.1 release. Several upcoming Carbon Mac OS X apps require 10.1.
- Scott
I would like to know if there are any IP issues the GNUStep have had, or will have to deal with?
It is legal for them to write implementations of the OpenStep/Cocoa APIs. But there are going to be walls. No Quartz or QuickTime, for example. These are considered core components of Mac OS X.
- Scott
6000 die every DAY in this country. And 100,000 humans die every die on this planet.
Quantity is not the only issue. It's the fact that the deaths were so sudden, in such a small area, and the result of malicious intent. These people were executed. Many of the deaths you're talking about are due to age, disease, and some that have voluntairly entered themselves into conflict. At least some have time to prepare, make sure their families are taken care of. The people in the world trade center were doing paperwork when a 757 flew into the building.
- Scott
Hell if you wanted to mirror all the linux distro's you could do it with rsync.
So use Linux.
doesn't have big bandwidth friends willing to mirror it for free
That really has nothing to do with it. Apple doesn't distribute software through third parties. This isn't just another *nix distribution. If you want to mirror something, mirror Darwin. It's a perfectly capable *nix OS.
because Apple doesn't give a damn thing back to the community from which it stole its code from
Oh, please. Everything they "stole" (and modified) is re-released to the community as a complete OS in Darwin. They've introduced a lot of new code to the community -- NetInfo, OpenPlay, NetSprocket, QuickTime Streaming Server, and CDSA. They've also submitted patches back to the BSDs and Apache.
- Scott
The Paris expo starts on September 26. It's probably a reasonable bet it will show up then.
- Scott
The answer is a pretty complicated one and to explain that would require some basic knowledge that you just can't squeeze into a 30 second commercial.
Here's an eight minute video that aims to do that. It's in QuickTime, btw.
- Scott
care to back that up with some fact? there are ALOT of Solaris boxes out there.
Apple did $19 million in sales of Mac OS X the first weekend it was out. Assuming everyone in that number paid the full $129 price, you get about 150,000 right out of the gate. This doesn't take into account all the beta testers (100,000 in all) that got a $30 discount. Then you tally the developers, educators, and Apple specialists that get it for substanially less or free outright (this revenue might not even been counted in the $19m since it's through special channels).
Then add in that every machine Apple ships now comes with Mac OS X, and that they shipped 827,000 machines last quarter (which ended June 30). And they've certainly sold some copies of OS X off the shelf in the last 5 months. And none of that counts burned copies of Mac OS X or Darwin users.
I suspect it's a relatively big number, probably over 1 million at this point. I'm guessing that it will be at least 2 million year's end. And note that all of this happens despite the fact Apple has run zero TV or magazine advertisements for Mac OS X at this point. They are certainly holding off on marketing campaign until at least until 10.1, and very likely until Office 10 comes out (sometime this fall). I'm not clear on whether the measurement for largest Unix vendor is the number of units sold in a particular period of time (which I suspect Apple is kicking ass on), or the total installed base.
- Scott
At last, somebody actually gets this right:
"Apple negotiated a deal with Xerox; in return for a block of Apple stock, Xerox allowed Jobs and his team to tour PARC, take notes, and implement some of the ideas and concepts being bounced around at PARC in their own creations."
Pirates seriously messed with history in this regard, having never touched on the deal Jobs made with Xerox, and the made-up commentary by the "Wozniak" character.
But on the downside, the author doesn't spell Jef Raskin correctly.
These are harsh words. If I have wronged you, please email me and let me know how I can address it.
- Scott
Heh, yeah, companies like MS have had a real tough go of it trying to turn a profit on an OS for x86 hardware.
Who else besides MS is making money doing it? The reason there's no money in it (other than for MS) is because of MS.
And OS X is derived from OPENSTEP, which already ran on x86 hardware. Darwin has an x86 build, and there are persistent rumors of an internal x86 OS X build at Apple.
I'm sure Apple could get OSX running on x86, and probably has. The hurdles I was referring to weren't technical in nature, but rather things like "who would buy this and use it at the exclusivity of Windows?" Many developers won't bothering port apps if users can already run Windows on the same machine -- they'll just buy the Windows software.
The only real hurdle is getting Apple to stop thinking of themselves as a hardware company and start marketing their software as a separate product.
From a financial perspective, Apple is a hardware company. From a product development perspective, Apple is neither hardware nor software company -- it is both. The hardware and software have a symbiotic relationship. The hardware helps sell the software and vice-versa. Separate one from the other, and you lose a lot of the value.
Never developed on a NeXT system, I see. The "porting" cost was essentially the time it took to go into ProjectBuilder and click the checkbox for the desired platform.
Office and IE aren't written in Cocoa, and they actually use CodeWarrior for IE, not PB. I'm guessing it's the same for Office. But I wasn't talking about the development time. I meant they wouldn't release such a product for business reasons. OSX for x86 would be in direct competition with them -- they wouldn't support it.
- Scott