This may have been modded +5 Funny, but in all honesty it's a very telling/scary story. AOL is shedding Mozilla. Yes, they've chipped in $2M to help run the foundation, but what happens in a few years when the Foundation has A) run out of money, and B) hasn't gotten any significant donations?
Let the "Mozilla is dead" postings start in 3..2..
Does the book cover security at all? I haven't yet met a wireless network my version of AirSnort didn't like.
Until there is a reliable method of securing a wireless network, I would recommend that nobody set up any more detailed of a network than a couple of access points. You're just inviting people to pirate your bandwidth.
http://www.eyesbeyond.com/freebsddom/java/jdk14.ht ml
"The JDK 1.4 patchset for BSD is currently considered of ALPHA quality. It should be considered a work in progress and use in a production environment is at your own risk."
That's not what I mean when I say I want a native 1.4 JDK. I want a production-ready JDK.
I can't speak for the other BSDs, but under FreeBSD, Java is in utter shambles. Anything beyond the 1.1 JDK requires you to run the JDK under FreeBSD's linux compatibility layer, which does two things: eat up a whole lot more RAM than it needs, and slows things down, noticeably under load. The FreeBSD group needs to approach Sun and ask them for a native license-- I have to believe that a back-port from Mac OS X won't be that difficult.
Besides, where in the article did it mention the language? Since IBM is in the fray, they're most likely using Java under Websphere.
Where are these savings coming from? Surely not entirely from switching to Linux.
I'd be willing to wager that most of the cost savings will be in manpower, usability, etc, of the home-built software itself. Additionally, unless they're deploying Linux on the exact same hardware that their old system was running on, you can't credit Linux with the operating cost savings.
For example, let's say that they were running the old payroll system on some cluster of Pentium 2 or Pentium 3 machines. Those machines supported X concurrent users. With today's hardware, you can support X concurrent users with half the amount of hardware. Remove half the hardware, and you can potentially remove half your support resources. Congratulations, you've halved your operating costs.
I think "using Linux" is just a side-note to this story. Systems evolve, and get easier to use, more powerful, and require less support, regardless of which operating system they're using.
It astounds me that PDA makers continue to believe that they can charge more than $250 for their hardware and get any serious amount of sales. I haven't noticed a whole lot of innovation from PDA-makers (other than the Hiptop) and their core functionality (contacts, appointments, notes) has been co-opted by everyone from the cellphone makers to Apple with the iPod.
Until someone can give me some really compelling reasons to upgrade from my old Handspring, I will continue to use my money to purchase more reasonable hardware upgrades: that is to say, more RAM for the laptop, bigger drives for the desktop, etc.
Although Final Cut Pro may render things faster and all that, I like Adobe's take on user interface and sometimes, they do a better job than apple.
Premiere is well-known for having a convoluted interface (in respect to video slice-and-dice). Look at the Avid system, look at Final Cut Pro, then look at Premiere. Premiere has more in common with Photoshop than it does with the Avid, and (as much as people may hate to admit it) as Avid goes, so goes the industry.
What if at the office a user is running windows and Premier, wants to take the project home and only has his nice new dual 2ghz G5 sitting there.
Simple: one of your machines exports its edits into EDL, you transport your EDL file to your home, and you work on it from there. Why you would be running Windows and Premiere at the office is beyond me, though. That software is the buggiest, crash-prone POS that I've ever seen. I'd rather work with Vegas on Win32 than on Premiere. Granted, I'd pick FCP over both in a heartbeat.
Just curious - does performance of Apache really matter, i.e. wouldn't you reach the capacity of your app server (Resin in this case) way before you reach any limit of Apache?
Nope. Think about this-- say you have a page that is made up of:
- 1 JSP page
- 1 CSS file
- 1 JS file
- 7 images
90% of your content is static, and can therefore be served up by Apache. Even by limiting Resin's threads to 250 simultaneous, you can safely set Apache up to handle 2500 concurrent requests, realizing that 90% of those requests will be handled by Apache itself.
Another bonus speed boost that we use in Resin is the ExpiresFilter, which (for pages that don't use sessions) acts as a reverse proxy (in memory). By setting the filter to cache pages for even as little as 5 minutes, you get a huge performance increase by serving up 99% of your JSP hits straight from cache. That will cause that thread in Resin to be returned to the thread pool that much quicker.
It's the small tuning pieces that add up to really big performance gains; I can honestly say that I can serve up pages almost as fast as a server that's doing nothing but static content.
"yet we dropped WebLogic in favor of Tomcat due to horrible performance."
If all you're doing is XSL transformations, Weblogic shouldn't be any slower than Tomcat if you're using the same XSL parser. That said, I understand the memory/services overhead that Weblogic has. If you aren't doing EJB, Weblogic is serious overkill.
This may sound like a bad pitch/endorsement, but you may want to consider switching from Tomcat to Resin. Resin provides all the same functionality that Tomcat does, and is quite a bit faster. Tomcat, remember, is still just a "reference implementation" of the Servlet and JSP specs. Resin has been written from the ground up to be speedy. Its DataSource pooling is second to none, and (imho) changing an application's configuration is a lot less painful under Resin than under Tomcat. Last I checked, Resin had a price tag of $500 -- comparable to Weblogic Express without all the BEA hassle.
The problem with Apache 1.3 is that each connection requires a separate instance of the child process, which in turn takes up 2 megs (or so) of memory. Multiply that by 500 concurrent clients, and you see the bottleneck right there.
With 2.0 in MPM mode, each process (which we have configured to take 250 threads/children) takes up about 30-40 megs of memory. 500 concurrent clients takes up 80 megs of memory, as opposed to the 1 gig of memory with Apache 1.3.
So the issue isn't that multithreading necessarily speeds up individual requests, but you can handle a lot more requests with a lot less footprint.
Holy cow, but you have done a lot of development work to duplicate existing efforts.
To give you an idea, in NetBeans/SunONE/JBuilder/etc, you model your database (or import the schema from an existing JDBC connection) and then right-click on the table you're looking to create a bean for, select (something like) "Generate Classes" and poof, the IDE does all your work for you.
NetBeans hooked into a CVS server. It offers a huge amount of functionality (nearly competitive with JBuilder) and it is free.
What Dbs do you use?
Oracle 8i, although we're migrating to Oracle 9 fairly shortly. High-availability, clustering, and reliability. Oracle cannot be beaten.
What web server?
Apache 2.0 in "worker" MPM mode. Multi-threaded, multi-process. Provides the stability of Apache 1.3 (multi-process so if one process crashes, no problem, they just get started right back up) along with a huge speed increase due to the multithreading. Changing from Apache 1.3 to Apache 2.0 in worker mode, tuned correctly, will give you a 500% capacity and speed boost, easily. We have gone from approximately 85 simultaneous connections max, running at about 200 requests per second, to over 2500 simultaneous connections running at 900 requests per second, on the same hardware.
Why?
You forgot the most important question. "What application server are you using?" We aren't using EJBs, so we only need to run a servlet runner. Resin is an amazingly quick app server for our purposes.
Your post is so incorrect, on so many levels, I can't begin to describe how wrong you are.
You've just named a grand total of two projects that have been able to stay afloat because of donations from the public; and only because these are extremely high profile projects. I'm not even sure Blender counts, because the original company that created Blender just sold the source code, they didn't continue to develop it.
Go ahead and ask the average SourceForge developer if they're able to quit their day jobs and continue their projects based upon PayPal donations. I dare you. I'll tell you right now, the positive response rate will be in the neighborhood of less than one percent. Less than one percent of open source developers are able to write open source for a living.
Similarly, if you switch the music business over to a harebrained donationware scheme, you will absolutely kill the independent artist, the person who languishes in his/her studio day in and day out just so they can sell a couple thousand copies of an album for $10 a pop.
That's the great thing about capitalism: companies charge what the public will bear. You may not be willing to pay $20 for an album, and that's perfectly fine-- that's your perogative. However, you may be willing to pay $.99 for the one good song off an album, in which case I would refer you to the iTunes Music Store.
But under no circumstances should the entire industry go to a "take it all, and maybe you'll throw us a dollar" model. It will kill the independent musician.
I understand that your post is a troll, but...
Lest we bring up this age-old argument again...
Donationware will never pay anyone's rent. The same goes for music.
Substitute "Netscape" for "Netflix", and "Microsoft" for "Wal-Mart" and your comment seems frighteningly on-target.
Re:An honest question - who cares?
on
AAC Put To The Test
·
· Score: 4, Informative
"...I encode it into mathematically loseless [sic] MP3s..."
Not possible. MP3 by its very nature is a lossy encoding scheme, hence there will always be artifacts when you pass the audio through the encoder. You may not be able to hear the quality change (even after passing the files over and over and over through the encoder) but you will be generating noise.
As far as your original question, it all comes down to file portability. It takes people a bit longer to send a 65 meg wav to their friends, compared to a 6.5 meg mp3.
"What more can you ask for in a great conference?"
on
GnomeDex 3.0
·
· Score: 1
Inexpensive airfare? I don't know about you, but flying to LAX/JFK is a lot cheaper than flying to DSM...
I think you're going to find that DVDs, or some other physical medium by which to sell movies (VHS, Laserdisc, etc) will never go away, for the simple reason that they are part of a "pipeline" by which a movie studio makes money off the release of a movie.
Consider this:
First, the wide release in theaters. $10 out of your pocket for a ticket (a majority, if not all of your ticket price, goes to the studio).
Then, the in-flight movies, the hotel rooms, and other "semi-controlled" environments by which a studio can license to third-party vendors. $5-$10 tacked onto your plane fare, your hotel room, etc.
Then, the movie networks-- HBO, Showtime, Skinemax, etc. Another dollar or so that you pay, indirectly, to the studio by way of your cable bill.
Then, the DVD/VHS release. $25-$45 (if it's a "special edition").
Finally, the major networks -- ABC, CBS, NBC, Fox. No money directly out of your pocket, but the networks pay out of the nose to the studios to be able to show a popular movie in primetime.
All of these selling points take place a few months or so after the previous one. You don't get current movies on the plane, but you get movies that were in theaters just a month or so ago.
etc etc, I hope you get my point. There are many points along this chain by which the studios can collect money for the movie. By saying "DVD is dead" you're eliminating one of those sell points. That will never fly with any studio exec.
Instead, think of this: insert the VOD service somewhere in that timeline. Let's say, in between the in-flight/hotel room and the major movie networks. Pay $5-$7, and you can see the movie you want when you want. Pay-per-view is somewhat like this, and if any selling point changes, it'll be the pay-per-view system. No longer will you have to wait until 4pm to see the movie you want to watch, you'll be able to have it start at 3:47 if you want.
As far as codecs go, that is the absolutely last thing on the studio head's mind. I guarantee you that whatever the major cable operators are using, that's what you'll see. Right now it's mostly MPEG-1, with a smidgen of MPEG-2 in some systems. For VOD, you'll need a more intelligent head-end system and a better set-top box. There might be some concern around conserving bandwidth, but I highly doubt it. You're getting HD streams of ESPN these days on the current systems, so we won't require a more efficient codec to do VOD.
"I'm too cheap to purchase an awesome product from a company that needs consumers, so how can I build my own [insert product here]?"
This is -1 Redundant, but just buy a Tivo. The Tivo service alone is worth the subscription fee, and Tivo v2 users who have a Mac will absolutely love the new Media Pack, allowing for Rendezvous discovery of iTunes / iPhoto libraries.
"You should _always_ try to find the best (or most optimal, I should say) approach/solution to your problem."
I disagree.
You should always try to find the best, most efficient, most cost-effective approach/solution to your problem.
If your internal time is billed out at $50 per hour, and you want to save your company money, you aren't going to spend 4 hours to create a custom garbage collector just to save another 5k of RAM-- you're going to go out and buy another stick of memory.
I agree wrt bad coding habits and the like, but everything has its price. If someone can push an application out the door rapidly that can still be easily maintained and only requires a bit more memory or a bit faster processor, I'm more than willing to expense the money for that new hardware.
I forwarded this article to our sysadmins, and they basically laughed it off. At least for web-based applications, almost none of these points apply. The article talks about the author's hatred of JVM startup times (which don't apply for an application server) and exception verbosity (which any real java developer will catch and deal with himself, rather than leaving it up to the sysadmin(?) to deal with).
I challenge you to make a C++/C# application that is thread-safe and can scale to millions of pageviews per day without writing a ton of supporting code. With a good J2EE app server, a java coder essentially just has to wrap his thread-unsafe code in a syncronized() statement, and he's done-- his app is now thread-safe.
Additionally, the "cross-platform doesn't matter for sysadmins" is a false statement; our CIO asked our net ops group "what would be the impact of us moving to an Intel platform?" and our sysadmins (after consulting with the coders) replied "absolutely no impact". That made our CIO very, very happy. Again, I challenge you to move your C++ apps from Solaris to Linux, or even to Windows, without any hiccup.
All of these other arguments are very specious: "I don't have enough RAM" will get you a reply of "go down to Fry's and spend $125 on another GB" every time. Processor speeds, even on Sun boxes, is getting to the point where the processor will never be a bottleneck for anything. Sure, java won't run as fast as a natively-compiled app. Neither will perl, php, tcl, or what have you. Raw processor speed is not as important when you have a couple of GHz to play with.
Slashdot Mirror
Let the "Mozilla is dead" postings start in 3..2..
TSI.
Until there is a reliable method of securing a wireless network, I would recommend that nobody set up any more detailed of a network than a couple of access points. You're just inviting people to pirate your bandwidth.
http://www.eyesbeyond.com/freebsddom/java/jdk14.ht ml
"The JDK 1.4 patchset for BSD is currently considered of ALPHA quality. It should be considered a work in progress and use in a production environment is at your own risk."
That's not what I mean when I say I want a native 1.4 JDK. I want a production-ready JDK.
Besides, where in the article did it mention the language? Since IBM is in the fray, they're most likely using Java under Websphere.
I'd be willing to wager that most of the cost savings will be in manpower, usability, etc, of the home-built software itself. Additionally, unless they're deploying Linux on the exact same hardware that their old system was running on, you can't credit Linux with the operating cost savings.
For example, let's say that they were running the old payroll system on some cluster of Pentium 2 or Pentium 3 machines. Those machines supported X concurrent users. With today's hardware, you can support X concurrent users with half the amount of hardware. Remove half the hardware, and you can potentially remove half your support resources. Congratulations, you've halved your operating costs.
I think "using Linux" is just a side-note to this story. Systems evolve, and get easier to use, more powerful, and require less support, regardless of which operating system they're using.
Until someone can give me some really compelling reasons to upgrade from my old Handspring, I will continue to use my money to purchase more reasonable hardware upgrades: that is to say, more RAM for the laptop, bigger drives for the desktop, etc.
- 1 JSP page
- 1 CSS file
- 1 JS file
- 7 images
90% of your content is static, and can therefore be served up by Apache. Even by limiting Resin's threads to 250 simultaneous, you can safely set Apache up to handle 2500 concurrent requests, realizing that 90% of those requests will be handled by Apache itself.
Another bonus speed boost that we use in Resin is the ExpiresFilter, which (for pages that don't use sessions) acts as a reverse proxy (in memory). By setting the filter to cache pages for even as little as 5 minutes, you get a huge performance increase by serving up 99% of your JSP hits straight from cache. That will cause that thread in Resin to be returned to the thread pool that much quicker.
It's the small tuning pieces that add up to really big performance gains; I can honestly say that I can serve up pages almost as fast as a server that's doing nothing but static content.
This may sound like a bad pitch/endorsement, but you may want to consider switching from Tomcat to Resin. Resin provides all the same functionality that Tomcat does, and is quite a bit faster. Tomcat, remember, is still just a "reference implementation" of the Servlet and JSP specs. Resin has been written from the ground up to be speedy. Its DataSource pooling is second to none, and (imho) changing an application's configuration is a lot less painful under Resin than under Tomcat. Last I checked, Resin had a price tag of $500 -- comparable to Weblogic Express without all the BEA hassle.
The problem with Apache 1.3 is that each connection requires a separate instance of the child process, which in turn takes up 2 megs (or so) of memory. Multiply that by 500 concurrent clients, and you see the bottleneck right there.
With 2.0 in MPM mode, each process (which we have configured to take 250 threads/children) takes up about 30-40 megs of memory. 500 concurrent clients takes up 80 megs of memory, as opposed to the 1 gig of memory with Apache 1.3.
So the issue isn't that multithreading necessarily speeds up individual requests, but you can handle a lot more requests with a lot less footprint.
To give you an idea, in NetBeans/SunONE/JBuilder/etc, you model your database (or import the schema from an existing JDBC connection) and then right-click on the table you're looking to create a bean for, select (something like) "Generate Classes" and poof, the IDE does all your work for you.
I hate to meta-mod, but whoever modded this as 0, Troll has no sense of humor. +1 Funny for the sarcasm.
You've just named a grand total of two projects that have been able to stay afloat because of donations from the public; and only because these are extremely high profile projects. I'm not even sure Blender counts, because the original company that created Blender just sold the source code, they didn't continue to develop it.
Go ahead and ask the average SourceForge developer if they're able to quit their day jobs and continue their projects based upon PayPal donations. I dare you. I'll tell you right now, the positive response rate will be in the neighborhood of less than one percent. Less than one percent of open source developers are able to write open source for a living.
Similarly, if you switch the music business over to a harebrained donationware scheme, you will absolutely kill the independent artist, the person who languishes in his/her studio day in and day out just so they can sell a couple thousand copies of an album for $10 a pop.
That's the great thing about capitalism: companies charge what the public will bear. You may not be willing to pay $20 for an album, and that's perfectly fine-- that's your perogative. However, you may be willing to pay $.99 for the one good song off an album, in which case I would refer you to the iTunes Music Store.
But under no circumstances should the entire industry go to a "take it all, and maybe you'll throw us a dollar" model. It will kill the independent musician.
I understand that your post is a troll, but... Lest we bring up this age-old argument again... Donationware will never pay anyone's rent. The same goes for music.
Substitute "Netscape" for "Netflix", and "Microsoft" for "Wal-Mart" and your comment seems frighteningly on-target.
Not possible. MP3 by its very nature is a lossy encoding scheme, hence there will always be artifacts when you pass the audio through the encoder. You may not be able to hear the quality change (even after passing the files over and over and over through the encoder) but you will be generating noise.
As far as your original question, it all comes down to file portability. It takes people a bit longer to send a 65 meg wav to their friends, compared to a 6.5 meg mp3.
Consider this:
First, the wide release in theaters. $10 out of your pocket for a ticket (a majority, if not all of your ticket price, goes to the studio).
Then, the in-flight movies, the hotel rooms, and other "semi-controlled" environments by which a studio can license to third-party vendors. $5-$10 tacked onto your plane fare, your hotel room, etc.
Then, the movie networks-- HBO, Showtime, Skinemax, etc. Another dollar or so that you pay, indirectly, to the studio by way of your cable bill.
Then, the DVD/VHS release. $25-$45 (if it's a "special edition").
Finally, the major networks -- ABC, CBS, NBC, Fox. No money directly out of your pocket, but the networks pay out of the nose to the studios to be able to show a popular movie in primetime.
All of these selling points take place a few months or so after the previous one. You don't get current movies on the plane, but you get movies that were in theaters just a month or so ago.
etc etc, I hope you get my point. There are many points along this chain by which the studios can collect money for the movie. By saying "DVD is dead" you're eliminating one of those sell points. That will never fly with any studio exec.
Instead, think of this: insert the VOD service somewhere in that timeline. Let's say, in between the in-flight/hotel room and the major movie networks. Pay $5-$7, and you can see the movie you want when you want. Pay-per-view is somewhat like this, and if any selling point changes, it'll be the pay-per-view system. No longer will you have to wait until 4pm to see the movie you want to watch, you'll be able to have it start at 3:47 if you want.
As far as codecs go, that is the absolutely last thing on the studio head's mind. I guarantee you that whatever the major cable operators are using, that's what you'll see. Right now it's mostly MPEG-1, with a smidgen of MPEG-2 in some systems. For VOD, you'll need a more intelligent head-end system and a better set-top box. There might be some concern around conserving bandwidth, but I highly doubt it. You're getting HD streams of ESPN these days on the current systems, so we won't require a more efficient codec to do VOD.
This is -1 Redundant, but just buy a Tivo. The Tivo service alone is worth the subscription fee, and Tivo v2 users who have a Mac will absolutely love the new Media Pack, allowing for Rendezvous discovery of iTunes / iPhoto libraries.
I disagree.
You should always try to find the best, most efficient, most cost-effective approach/solution to your problem.
If your internal time is billed out at $50 per hour, and you want to save your company money, you aren't going to spend 4 hours to create a custom garbage collector just to save another 5k of RAM-- you're going to go out and buy another stick of memory.
I agree wrt bad coding habits and the like, but everything has its price. If someone can push an application out the door rapidly that can still be easily maintained and only requires a bit more memory or a bit faster processor, I'm more than willing to expense the money for that new hardware.
I challenge you to make a C++/C# application that is thread-safe and can scale to millions of pageviews per day without writing a ton of supporting code. With a good J2EE app server, a java coder essentially just has to wrap his thread-unsafe code in a syncronized() statement, and he's done-- his app is now thread-safe.
Additionally, the "cross-platform doesn't matter for sysadmins" is a false statement; our CIO asked our net ops group "what would be the impact of us moving to an Intel platform?" and our sysadmins (after consulting with the coders) replied "absolutely no impact". That made our CIO very, very happy. Again, I challenge you to move your C++ apps from Solaris to Linux, or even to Windows, without any hiccup.
All of these other arguments are very specious: "I don't have enough RAM" will get you a reply of "go down to Fry's and spend $125 on another GB" every time. Processor speeds, even on Sun boxes, is getting to the point where the processor will never be a bottleneck for anything. Sure, java won't run as fast as a natively-compiled app. Neither will perl, php, tcl, or what have you. Raw processor speed is not as important when you have a couple of GHz to play with.
Calling Java out because of memory requirements is laughable. That would be like saying mp3s are bad because they take up too much disk space.
"Besides, I don't like Sun - it's no better than Microsoft, just less lucky."
Sure. Like how Sun is opening up its Application Server, its Web Server, and its Directory Server. Yeah, just like Microsoft.
Congratulations! Your hardware may be useful for perhaps another 6 months, depending on how Sonicblue's bankruptcy proceedings go!