How can you claim to be pro-open source and pro-Linux, but maintain a website (according to former webmasters) where the free and linux versions of your player are intentially obfuscated and hidden?
1. "If you're not willing to help fix it then you shouldn't complain about it"
This happens a lot. I'll grant you this point.
2. "Open Source software allows you to get under the hood and fix problems" ...
this really isn't something your average user is going to do.
Survey all of the OSS out there, and how much of it is targetted to the Grandma sector of the computer using population? Very little. Most OSS projects out there are targetted to other developers, otherwise known as integrators. If what you do as a full time job is use JBoss, Ant, JUnit, JCoverage, and Eclipse to write 100 - 200 classes, you're pretty much an integrator at that point. The value of OSS at that point is that when a stack trace appears in a logfile, with a line number next to it, you can go into the OSS source code, look at the line that's throwing an error, and gain an understanding of "what's going on" in the block of code that's throwing an exception in your external library.
For example, when WebLogic spits an error that originates within one of their classes, you have to unjar their library, decompile their class, then re-compile their class, re-execute your test, and then you can finally look at the code that is causing the problem. In open source, you see an error occurred on line 253 of class Foo, and you look at line 253 of class Foo. It's just that simple.
The value is not so much in your ability to change the OSS, but more in your ability to view the OSS, understand it, learn from it, and solve a problem yourself rather than invoking support.
3. "All software should be free"
The article's main argument here is the classic "the world isn't free, why should the software I produce be free?" argument, which shows a narrow understanding of OSS.
If you develop a standalone product, you should be compensated. How many people develop standalone products? Very few. Most people are integrators that are customizing a general solution (n-tier via J2EE) for a specific use (fulfillment of book orders at Amazon.com). The software they write to facilitate this integration has no use outside of the customer who is paying for the custom software job. If only the customer sees value in your solution, how do you expect to sell that software?
Flipping the coin . ..
Let's say that while working on a custom solution (which is honestly what 75% of us do I'd say), you realize that OSS library X would be *great* for this integration, except it can't do A, B, and C. A, B, and C are valuable to other integrators out there. So, you make those changes, add them to the OSS library kit, continue to get paid, increase the capabilities of the library you're using (thereby giving back to the community that is keeping you employed by giving you (for free mind you) build systems, testing frameworks, application servers, etc, etc). The customer doesn't care that you've added namespace capabilities to an XML parser - all they care about is: do orders flow from the web site to the warehouse.
4. "Open Source software is always better than closed, proprietary software"
It normally is better. Closed source companies earn the majority of their revenue from service and support contracts. The initial up-front cost of an application server is dwarfed by the yearly subscription fees to support (which, by the way, usually extend for years). Closed source companies (rightfully so) are going to protect their revenue streams (support) and as a result are going to try to stifle any communication between two end users of their product.
Let's say that you and I are users of Product X and both have the same problem. If you determine (or receive from support) a solution, and post it on the Internet, then I can then find your
If you think a man that gasses his own people, has billions of dollars in the bank, funds Hamas suicide bombers, provided medical treatment to an associate of the 9/11 hijackers, and has publicly stated that he hates all Americans is _not_ a threat, you sir are insane.
What we're actually seeing now are more and more "free" alternatives to commercial software (thanks to the open source world). The only thing computer related that I've paid for in the past 5 years has been hardware.
I started out paying for Windows, Paradox, Harvard Graphics, and WordPerfect. Then Windows condensed Paradox, Harvard Graphics, and WordPerfect into Office so I just paid for Windows and Office. Then I switched to Linux altogether, but one can imagine the next progression of a Windows user is the discovery of OpenOffice, leaving Windows the only thing left to pay for. When you get to that point you come to the realization that maybe Linux *will* work for you.
So now I'm at the point where I _never_ pay for software, and I _gladly_ pay for hardware. I guess I'm way off from what Scott's thinking so one of us must be smoking crack. And I just got my last drug test back and it reported negative...
Definitely not feeling the "pay for software, give out free hardware!" trend. And the fact that Bill Gates agrees with him discredits his premise altogether.
What irritates me the most is that there usually is not an effective way to filter out the advertisements by those who are willing to pay for a service. It would be one thing people were willing to look at ads in exchange for a service.
If you want to market a service, offer an advertisement revenue based system for the people that can tolerate the ad nuisance but also offer a pay-as-you-go service that is ad-free for those of us willing to pay for convenience. TiVo is wildly successful because it allows people (with money to spend) to purchase a device that essentially kills off advertisements. You can very easily fast forward through ads (commercials) and it's really really great.
The bottom line is that we are barraged with advertisements almost every waking hour of the day. You wake up, and you see advertisements in the newspaper (even tho you paid for the paper). Brush your teeth, there are advertisements on the toothpaste container (try our new brand that helps get rid of gingivits!). Drive to work, advertisements on the side of the road. Listen to the radio, it's there (this traffic report brought to you by A&B Mortgage - for your mortage needs, go to A&B Mortgage). They are literally everywhere.
One day I tried to count how many forms of advertisements or sales that I encountered during the day. I stopped when I reached 100 by mid afternoon.
So for cripes sake, offer a way for those of us that have money and are willing to spend it, can avoid your blasted advertisements. Sell a subscription based setup for these hot spots, or offer a "after 5 truly free connects, you get ads or you have to subscribe" system.
Previously, the only way to scale was vertical. Adding more processors to a massively multiprocessor system was the only way to improve performance on many apps. It was the route took with the mainframe, and largely what Sun took as well.
This worked in a time where software was not available to permit horizontal scaling: distributing load across multiple systems. The difference is simple. Vertical scaling has you purchasing 1 system with N CPUs. Horizontal scaling has you purchasing N systems with 1 CPU each. Until recently, horizontal scaling was difficult and expensive.
This was true primarily because single CPU systems (primarily Intel or AMD) were slow. Our programming languages lacked the ability to gel together multiple components scaled scross multiple systems in a heterogeneous way. Then came XML. XML became the goo that revitalized the horizontal scaling movement. It came at a time when processors were preparing to cross the 1 GHz boundary.
Nowadays, with processor speeds approaching 3.5 GHz, XML easily parsable, and bandwidth on the cheap, it's possible to scale an application horizontally. It's quite easy (JBoss cluster, Oracle RAC, etc) to field a distributed load balanced system based entirely upon software. Lots of times you don't need to go vertical to achieve performance - you can simply add another 1 CPU system into the pool and you're off to the races. Distcc comes to mind as another example of this (a friend just pointed to a Knoppix live cd with distcc installed - this is exactly what i'm talking about with horizontal scaling).
Sun positioned itself in a market that rewarded vertical growth and scaling. That worked for awhile. It still works (there are problem sets that lend themselves nicely to vertical scaling). But, those problems are becoming more and more the outlier and less prevalent. Horizontal scaling solutions are cheaper and easier to implement in a lot of regards. Sun's screw up is that McNealy and company didn't position the company to capture revenues from horizontal AND vertical scaling.
Only now is Sun beginning to offer dual-Opteron based blade servers. Too little too late. If they had pioneered this 5 years ago, they would've planted the seed for a revenue growing crop of servers. But instead, they focused on the big iron and went vertical. Very sad...
Campuses are usually large plots of lands. It's commendable that universities are providing wireless networks at all!
To add to the accomplishment, many buildings are older and made of cinder block (at least around where I live - College Park MD). 802.11 through concrete and/or cinder blocks is like trying to drive a Zamboni through a bog. The fact that any wireless penetrates buildings and reaches students in class is quite amazing imo.
Wow, a "multi-national" company, eh? That sounds pretty impressive.
If someone in Europe uses my open source software, does that mean I'm multi-national too?
What about if I am a consultant and somebody in Japan sends me an email with a question - am I then qualified to state an opinion on what Apple should do?
Would you agree that they are more common now than 5 years ago? That's the point I was trying to make.
5 years ago I can't recall seeing anybody with a mac laptop. Now I know 3 different people with them that love them. They previously hated Apple. What a turnaround....
Just because the server works under Linux does not mean that the company mentality has been one that is favorable to Linux users. There are microsoft plugins for Apache that allow FrontPage to publish content - does that mean that Microsoft is friendly towards Linux?
There are projects out there that are agnostic towards operating systems. Apache httpd, Gaim, WebLogic, Firefox, and Python are examples of this. Each project has downloads for many different operating systems, and beyond that, the mailing lists are amicable to users posting questions related to platform X. It's not: "Here's the.exe install for our program. Use it and you are on your own." That's the impression I receive when I go to real.com -
For a long time it was difficult to find the Linux version of the real player. When you did find it, it was statically linked for the longest time (only recently have they started rpm'ing it). And it's rarely updated. A month or so ago I spent 15 minutes looking through their site before finding the Linux Real player. After finding it, downloading it, and installing it I found out that it was the same version I installed almost 2 years ago!
I *know* the Windows client has changed in the last 2 years. Why hasn't the Linux client? Because Real doesn't care about Linux! You're accurate in saying that Real doesn't have a customer base in Linux that warrants further development, and that to me is the definition of "Linux unfriendly."
How many people that use Gaim do so under Windows? I think me and my buddy Chris are the only ones. How many people install Apache httpd under Windows? Maybe a dozen. But the projects still ship binaries for Windows. And the mailing lists are still responsive to Windows users. That's "Windows friendly" - why can't Real be "Linux friendly"?
Apple has come a *long* way in the past few years against really long odds. The OS X platform has revived interest in the PowerPC platform, and nowadays people with Macs (G5 desktops or G4 laptops) are prevalent. Combine that with Apple's music revolution (online music store) and their iPod and I think it's safe to say that Apple has really pulled itself up out of the dungeon.
Real on the other hand is one of the most misunderstood companies out there. Legitimate on the exterior, Real is all but that at it's core (http://jogin.com/weblog/archives/2004/03/06/real_ reply).
Real is deceptive, not technologically innovative, and unfriendly towards Linux.
Apple partnering with Real would be a horrible position to take.
It took a lot of work to get Darwin and Panther to work. No doubt Apple has *very intelligent* people working for them. Take some of the talent pool, and direct them towards developing a streaming media protocol that leverages existing formats (mpeg for example). Real hasn't done anything quite innovative lately (yes, their protocol was innovative when it came out ?5? years ago).
I have no doubt in my mind that Apple could put together:
a.) a more efficient wire protocol
b.) reach more people than Real
c.) make the interface intuitive and able to be skinned / themed
d.) do this in less time
Real is dying (search/. for Real and you'll find posts about MLB suing them and radio stations considering ditching them in favor of media player). Apple hitching their wagon to Real is flat out dumb.
Another equally valid motivation is the desire to apply technologies you learn "on the job" to hobbies you enjoy "off the job." If you can connect the positive feedback loop, there's no limit to what you can do.
For example...
During the day I work on a web services project that primarily uses Java as the implementation language. We catalog earth science metadata. I've learned an awful lot about web services because of what I do on the job, but it's unfortunately all in Java.
I'm also interested in meteorology. So at night I tinker around with my weather station console using perl and python (and some Java). Because of my exposure to web services at work, I thought it would be fun to publish my weather data using web services at home. But, I don't like Java too much. So begins the process of learning and patching the perl/python web service libs to support more functionality.
Where this becomes interesting is that recently at work we had to stand up some services in a really short amount of time. Java would've taken too much time and would've been very difficult to manage. Drawing upon what I learned "off the job" on my weather project, I was able to stand up the services in python and perl in a very short period of time. Being able to focus 8 hours a day on perl/python web services afforded me the time to make more patches to the library. More patches created more possibilities using the web services library.
I'd then go home, and exploit those patches in my weather project. This opened up new potentials for my weather project, which helped me to push out the envelope a little bit further. Go back to work the next day, apply what I did in my weather project the night before. Find more stuff to patch in the open source libs, and implement it. Go home, exploit the patches I made during the day.
Open source can be used as a way to one-up what you worked on at work during the day, and can allow developers to apply technologies they find interesting (at work) to domains they are interested in (at home). It is the application of 8 hours of research in a lab (work) to the real world (your open source project). It not only helps you grow technologically, but it can make you happier at work, as you think of all the different things you can implement tonight on your open source project as a result of what you're learning technologically today at work.
What is it about testers and their negative reactions to developers writing tests? Is it out of fear of job security? I don't understand why so many testers frown upon or discard tests written by developers as worthless, or second rate, to the tests that they have written. Indeed, many times what accompanies test dismissal is the comment of "Developers don't know how to test software." Nevermind the lack of supporting details to back up this broad generalization.
What to me is so strikingly insane is that at the most primitive levels, testers write tests. What kinds of tests they write vary in size, scope and purpose. Developers, through unit tests, are technically doing part of the the tester's job. They produce tests! Sure, they are unit tests, but they are still valuable from the standpoint of software verification. Even if a tester walks away from them with simply a better understanding of how the software is put together, does that not make them valuable or important?
Too many times do testers toss away unit tests as worthless (or in Moses' case "hackish") simply because they were not written by a tester. Tell me what qualifications you must have to be a tester and to write tests. What are your criteria for considering a test valid or valuable? Now tell me how I can run the litmus test against my test to see if it passes what you consider to be the qualifications for inclusion into a suite of tests.
Were the best interests of the project (not the individual) ranked at the top of the importance list, I would expect testers to gleefully accept developer unit tests. Not only do they show accuracy in the software, but they more importantly demonstrate a developer's willingness to test and prove functionality. "Here's my code, it implements requirements X, Y, and Z, and here are the unit tests that demonstrate the functionality." Given that, a tester needs to tie together a high level interaction test or execute the regression tests. But the developer has gone a long way to help out the tester, and more times than not the tester pushes back with some assinine comment like "developers don't know how to write tests."
Successful software teams are not like the 4x2 tetris block, where the design team hands off UML to the developers to implement, who then hand off the code in an assembled version to the testers to verify. Successful software teams are a coagulation of the + tetris blocks where developers perform some requirements analysis and testing while at the same time coding. Testers pick up some system administration. And system administrators do some testing and even development. This type of cross-pollinated structure on a team keeps code velocity high, job competition to a minimum, and leads to higher overall satisfaction (generally speaking, of course;-)).
Your view of unit tests as hacks without the proper overall test plan shows your inflexibility to cohabitate with developers willing to test on your project. Archaeic views like this usually lead to unsuccessful projects. Take a moment to look back over your resume and reflect on the various software projects you've worked on. Ask yourself what developement environment existed, and if the project was successful. My guess is you'll notice a pattern.
Here's a slightly mischievous, perhaps sleazy, method of avoiding out-and-out copying of proprietary commercial code from one company to another: Make as much of it as open source as possible.
For example, say you're developing a set of components that will call each other using SOAP. You know that the components will be implemented in different languages, so you'll need to perform an interoperability study to make sure that everything works properly. There certainly isn't anything proprietary, or commercially viable from an exercise such as this. So talk to your boss about doing it as an open source experiment.
Set up a project somewhere, and try to dump as much "study work" (these can be stubbed out prototypes) into it as possible. Then, being open source, you can use the prototypes as reference material when you move on to another company.
In our project I was able to perform all of our interop work (e.g. Can perl call python services? Can java call perl services?) in an open source project. There was tremendous knowledge gain as a result, and the results are portable across employers. The only thing you have to make sure you do is not violate any company rules for release of source code. Make a point to say that you're not releasing any existing source code, you're writing *new* prototype source code in an open manner and that nothing proprietary or secret exists in said prototype code.
Doing so allows both parties to achieve their goals: you get to keep a reference guide for future projects, and your company gets to keep it's secret code secret.
There are numerous licenses in existence that would allow Sun to maintain their closed source product that probably would not be against RedHat policy.
I think the crux of the issue with RedHat is that:
a.) Sun wants you to download Java only from Sun
b.) RedHat wants to redistribute Java via the RedHat end user license.
The two don't have to be mutually exclusive. I don't understand why Sun can't just let "other people" (RedHat, FreeBSD, etc) distributed their binary code without checking in at Sun.com first.
As a java developer who earns an income based upon Java's success, I really want to see Java succeed on the desktop because it opens up more development avenues for me and other java developers. And I think that Sun has an interest in java succeeding on the desktop as well (their Java Desktop would seem to indicate this). With technologies like Flash that are so nice looking, so easy to install, and lots of times already integrated on your platform - you would think that Sun would be doing __everything_in_its_power__ to help foster the growth of java on the desktop.
I would think Java would be out there lobbying Dell and Compaq pumping them to install WebStart on their desktops. Or put in an up-to-date JRE into IE. Or . . . put in a stinking applet viewer into the Mozilla that ships with the Linux distro most commodity users install.
But they don't. Instead they sit back, come up with a dozen or so mime-types that represent a Java Applet, make it prohibitively difficult to install the correct.so file into your browser (rarely do the already compiled.so files line up with your browser version), put out a dozen or so different sub releases (JDK 1.4.2_03 build 13? come on...), and then watch with confused looks on their faces as Flash takes over the world of client side GUI development.
Come on Sun. Wake up! I want java to succeed on the desktop as much as you do. You guys clearly haven't figured out how to make Java pervasive - maybe us assclowns at home can figure it out. Just give up the EULA rights to Java so that one of us can figure out how to do, patch it into a vanilla distro (like Fedora), and let you reach the end users you've failed to reach since you came up with applets years ago.
There's nothing like knowing a solvable problem exists that you can't even begin to troubleshoot because some asshat lawyer somewhere wants you to sign their EULA instead of the one from another company (which is frequently the same stinking one).
One of the big problems with Java is the license. Here are some issues that real people have faced:
1.) RedHat couldn't put a JVM in their desktop OS w/out including the Java license in anaconda and having the end user agree to it at install time. As a result, RedHat couldn't set up Netscape and Mozilla to run Java applets seamlessly and out of the box.
2.) FreeBSD couldn't include Sun's JDK in the ports tree out-of-the-box. An admin pays $$$ for cut CDs or spends time to download ISOs so that they don't have to do a network install. When they find go to build Java on FreeBSD they are told by the ports tree to go "agree to Sun's license and download the JDK from http://java.sun.com/blah/blah/blah". Not only is it annoying to have to download an extra component that isn't included on the ISO, it leaves a poor taste in the admins mouth for Java. And come on - admins are the last people developers want to irritate.
I can understand Sun's position with not open sourcing Java. Although relatively uninformed on the topic, I don't see any prevailing reason to make it open source - there are open source implementations of the JDK other than Sun's - go with them. But for cripes sake change the farking license.
It is a sad sad statement that I, as an enterprise java developer of 6 years, am unable to get applets to work appropriately on my Linux desktop.
I found that the cable tuner boxes *always* lagged behind the quickness of satellite tuners. I'd press a channel and then have to wait for nearly 2 seconds between when TiVo hit the "done" signal for the digital cable box.
This could not be more true. The guide for Comcast cable (no matter where I go) is horrific. That sleezy gold background, with FF0000 on top of 0000FF brings me to tears - do they honestly believe that the brightest blue next to the brightest red is a *good* idea?!
The usability is poor, the font looks like something I produced on Apple's Paint Shop Pro back in 1992, and the ads are annoying.
Compare that to a TiVo or satellite guide, which often times features smoother more legible fonts, a transparent background (allowing you to view your current program while browsing the guide for other programs), allows you to go forward and back in time, features more than 5 channels per page, and supports page up and down - and I don't imagine why anyone would go with cable.
Have you been to Best Buy lately? You can purchase a 5 MP camera for $300. How can that be?! Because the camera delivers an effective rating of only 2.0 MP. Somehow the manufacturers are able to tout their product as a 5 MP camera.
What's going on here is the manufacturers recognize that consumers of electronics are sensitive to product numbers. When was the last time you heard of someone walking into Sears and purchasing a dishwasher because it has an R52JU actuator servo? Never. But, how many times have you heard of someone walking into Best Buy and purchase PC133 or PC2100 memory? All the time.
HP and Toshiba know that laptop purchases are sensitive to owning a Radeon 9200 (just like how digital camera makers know that purchasers are sensitive to owning a 5MP camera). It's not surprising at all the manufacturer is willing to futz with the model number to deceive the consumer.
The real question is: what are you going to do about it?
Moreover, the NASA of today is not the NASA of the 60s. Today's NASA is a politically correct beurocracy, where they are held to equal opportunity hirings. Therein lies the problem: going to space and back is *not* something a random cross section of the country's population is capable of realizing. Going to space and back is something that only the cream of the crop can do. But since that doesn't give every hillbilly redneck a chance, it's not fair, and what's not fair is changed.
NASAs not going to change unless society changes and people own up to not being up to a task.
I work for a NASA contractor. We put in a purchase order recently, and after waiting 2 - 3 months (this was for a $12000 purchase), we recently found out that we'll have to wait another couple of months. Turns out the procurement system for *all of* NASA only uses 4 digit ids for procurement. 4 digit ids?! What beatnick came up with that lame idea?
We need to privatize space flight so that companies can be formed that only hire the cream of the crop. Not this lowest common denominator bullshit - it's led to both the Challenger and the Columbia going Tango Uniform.
I have a possible solution that I believe fits both camps of convenience and security.
For starters, don't change SMTP. Leave it be.
Adopt the follow standard at the mail user agent level:
Mail encrypted using your public key is "trusted", and will appear in your unfiltered INBOX. You can distributed your public key to whomever you see fit, and when they send you mail you'll automatically get it.
Mail not encrypted using your public key is subject to the filtering methods that exist for detecting spam (bogofilter, spambayes, spamassasin, etc). Periodically scan your non-whitelist email from time to time to see if anything is in there that you are interested in. If so, send that fellow your public key.
It's not a perfect solution, but it does address some of the problems we currently have.
Slashdot Mirror
How can you claim to be pro-open source and pro-Linux, but maintain a website (according to former webmasters) where the free and linux versions of your player are intentially obfuscated and hidden?
Just think how fast that scrollbar will fly across when they install Fedora Core 2! It'll probably take 2 seconds!
-c
This happens a lot. I'll grant you this point.
Survey all of the OSS out there, and how much of it is targetted to the Grandma sector of the computer using population? Very little. Most OSS projects out there are targetted to other developers, otherwise known as integrators. If what you do as a full time job is use JBoss, Ant, JUnit, JCoverage, and Eclipse to write 100 - 200 classes, you're pretty much an integrator at that point. The value of OSS at that point is that when a stack trace appears in a logfile, with a line number next to it, you can go into the OSS source code, look at the line that's throwing an error, and gain an understanding of "what's going on" in the block of code that's throwing an exception in your external library.
For example, when WebLogic spits an error that originates within one of their classes, you have to unjar their library, decompile their class, then re-compile their class, re-execute your test, and then you can finally look at the code that is causing the problem. In open source, you see an error occurred on line 253 of class Foo, and you look at line 253 of class Foo. It's just that simple.
The value is not so much in your ability to change the OSS, but more in your ability to view the OSS, understand it, learn from it, and solve a problem yourself rather than invoking support.
The article's main argument here is the classic "the world isn't free, why should the software I produce be free?" argument, which shows a narrow understanding of OSS.
.
If you develop a standalone product, you should be compensated. How many people develop standalone products? Very few. Most people are integrators that are customizing a general solution (n-tier via J2EE) for a specific use (fulfillment of book orders at Amazon.com). The software they write to facilitate this integration has no use outside of the customer who is paying for the custom software job. If only the customer sees value in your solution, how do you expect to sell that software?
Flipping the coin . .
Let's say that while working on a custom solution (which is honestly what 75% of us do I'd say), you realize that OSS library X would be *great* for this integration, except it can't do A, B, and C. A, B, and C are valuable to other integrators out there. So, you make those changes, add them to the OSS library kit, continue to get paid, increase the capabilities of the library you're using (thereby giving back to the community that is keeping you employed by giving you (for free mind you) build systems, testing frameworks, application servers, etc, etc). The customer doesn't care that you've added namespace capabilities to an XML parser - all they care about is: do orders flow from the web site to the warehouse.
It normally is better. Closed source companies earn the majority of their revenue from service and support contracts. The initial up-front cost of an application server is dwarfed by the yearly subscription fees to support (which, by the way, usually extend for years). Closed source companies (rightfully so) are going to protect their revenue streams (support) and as a result are going to try to stifle any communication between two end users of their product.
Let's say that you and I are users of Product X and both have the same problem. If you determine (or receive from support) a solution, and post it on the Internet, then I can then find your
If you think a man that gasses his own people, has billions of dollars in the bank, funds Hamas suicide bombers, provided medical treatment to an associate of the 9/11 hijackers, and has publicly stated that he hates all Americans is _not_ a threat, you sir are insane.
What we're actually seeing now are more and more "free" alternatives to commercial software (thanks to the open source world). The only thing computer related that I've paid for in the past 5 years has been hardware.
I started out paying for Windows, Paradox, Harvard Graphics, and WordPerfect. Then Windows condensed Paradox, Harvard Graphics, and WordPerfect into Office so I just paid for Windows and Office. Then I switched to Linux altogether, but one can imagine the next progression of a Windows user is the discovery of OpenOffice, leaving Windows the only thing left to pay for. When you get to that point you come to the realization that maybe Linux *will* work for you.
So now I'm at the point where I _never_ pay for software, and I _gladly_ pay for hardware. I guess I'm way off from what Scott's thinking so one of us must be smoking crack. And I just got my last drug test back and it reported negative...
Definitely not feeling the "pay for software, give out free hardware!" trend. And the fact that Bill Gates agrees with him discredits his premise altogether.
What irritates me the most is that there usually is not an effective way to filter out the advertisements by those who are willing to pay for a service. It would be one thing people were willing to look at ads in exchange for a service.
If you want to market a service, offer an advertisement revenue based system for the people that can tolerate the ad nuisance but also offer a pay-as-you-go service that is ad-free for those of us willing to pay for convenience. TiVo is wildly successful because it allows people (with money to spend) to purchase a device that essentially kills off advertisements. You can very easily fast forward through ads (commercials) and it's really really great.
The bottom line is that we are barraged with advertisements almost every waking hour of the day. You wake up, and you see advertisements in the newspaper (even tho you paid for the paper). Brush your teeth, there are advertisements on the toothpaste container (try our new brand that helps get rid of gingivits!). Drive to work, advertisements on the side of the road. Listen to the radio, it's there (this traffic report brought to you by A&B Mortgage - for your mortage needs, go to A&B Mortgage). They are literally everywhere.
One day I tried to count how many forms of advertisements or sales that I encountered during the day. I stopped when I reached 100 by mid afternoon.
So for cripes sake, offer a way for those of us that have money and are willing to spend it, can avoid your blasted advertisements. Sell a subscription based setup for these hot spots, or offer a "after 5 truly free connects, you get ads or you have to subscribe" system.
Previously, the only way to scale was vertical. Adding more processors to a massively multiprocessor system was the only way to improve performance on many apps. It was the route took with the mainframe, and largely what Sun took as well.
This worked in a time where software was not available to permit horizontal scaling: distributing load across multiple systems. The difference is simple. Vertical scaling has you purchasing 1 system with N CPUs. Horizontal scaling has you purchasing N systems with 1 CPU each. Until recently, horizontal scaling was difficult and expensive.
This was true primarily because single CPU systems (primarily Intel or AMD) were slow. Our programming languages lacked the ability to gel together multiple components scaled scross multiple systems in a heterogeneous way. Then came XML. XML became the goo that revitalized the horizontal scaling movement. It came at a time when processors were preparing to cross the 1 GHz boundary.
Nowadays, with processor speeds approaching 3.5 GHz, XML easily parsable, and bandwidth on the cheap, it's possible to scale an application horizontally. It's quite easy (JBoss cluster, Oracle RAC, etc) to field a distributed load balanced system based entirely upon software. Lots of times you don't need to go vertical to achieve performance - you can simply add another 1 CPU system into the pool and you're off to the races. Distcc comes to mind as another example of this (a friend just pointed to a Knoppix live cd with distcc installed - this is exactly what i'm talking about with horizontal scaling).
Sun positioned itself in a market that rewarded vertical growth and scaling. That worked for awhile. It still works (there are problem sets that lend themselves nicely to vertical scaling). But, those problems are becoming more and more the outlier and less prevalent. Horizontal scaling solutions are cheaper and easier to implement in a lot of regards. Sun's screw up is that McNealy and company didn't position the company to capture revenues from horizontal AND vertical scaling.
Only now is Sun beginning to offer dual-Opteron based blade servers. Too little too late. If they had pioneered this 5 years ago, they would've planted the seed for a revenue growing crop of servers. But instead, they focused on the big iron and went vertical. Very sad...
Campuses are usually large plots of lands. It's commendable that universities are providing wireless networks at all!
To add to the accomplishment, many buildings are older and made of cinder block (at least around where I live - College Park MD). 802.11 through concrete and/or cinder blocks is like trying to drive a Zamboni through a bog. The fact that any wireless penetrates buildings and reaches students in class is quite amazing imo.
Wow, a "multi-national" company, eh? That sounds pretty impressive.
If someone in Europe uses my open source software, does that mean I'm multi-national too?
What about if I am a consultant and somebody in Japan sends me an email with a question - am I then qualified to state an opinion on what Apple should do?
Would you agree that they are more common now than 5 years ago? That's the point I was trying to make.
5 years ago I can't recall seeing anybody with a mac laptop. Now I know 3 different people with them that love them. They previously hated Apple. What a turnaround....
Just because the server works under Linux does not mean that the company mentality has been one that is favorable to Linux users. There are microsoft plugins for Apache that allow FrontPage to publish content - does that mean that Microsoft is friendly towards Linux?
.exe install for our program. Use it and you are on your own." That's the impression I receive when I go to real.com -
There are projects out there that are agnostic towards operating systems. Apache httpd, Gaim, WebLogic, Firefox, and Python are examples of this. Each project has downloads for many different operating systems, and beyond that, the mailing lists are amicable to users posting questions related to platform X. It's not: "Here's the
For a long time it was difficult to find the Linux version of the real player. When you did find it, it was statically linked for the longest time (only recently have they started rpm'ing it). And it's rarely updated. A month or so ago I spent 15 minutes looking through their site before finding the Linux Real player. After finding it, downloading it, and installing it I found out that it was the same version I installed almost 2 years ago!
I *know* the Windows client has changed in the last 2 years. Why hasn't the Linux client? Because Real doesn't care about Linux! You're accurate in saying that Real doesn't have a customer base in Linux that warrants further development, and that to me is the definition of "Linux unfriendly."
How many people that use Gaim do so under Windows? I think me and my buddy Chris are the only ones. How many people install Apache httpd under Windows? Maybe a dozen. But the projects still ship binaries for Windows. And the mailing lists are still responsive to Windows users. That's "Windows friendly" - why can't Real be "Linux friendly"?
Apple has come a *long* way in the past few years against really long odds. The OS X platform has revived interest in the PowerPC platform, and nowadays people with Macs (G5 desktops or G4 laptops) are prevalent. Combine that with Apple's music revolution (online music store) and their iPod and I think it's safe to say that Apple has really pulled itself up out of the dungeon.
_ reply).
/. for Real and you'll find posts about MLB suing them and radio stations considering ditching them in favor of media player). Apple hitching their wagon to Real is flat out dumb.
Real on the other hand is one of the most misunderstood companies out there. Legitimate on the exterior, Real is all but that at it's core (http://jogin.com/weblog/archives/2004/03/06/real
Real is deceptive, not technologically innovative, and unfriendly towards Linux.
Apple partnering with Real would be a horrible position to take.
It took a lot of work to get Darwin and Panther to work. No doubt Apple has *very intelligent* people working for them. Take some of the talent pool, and direct them towards developing a streaming media protocol that leverages existing formats (mpeg for example). Real hasn't done anything quite innovative lately (yes, their protocol was innovative when it came out ?5? years ago).
I have no doubt in my mind that Apple could put together:
a.) a more efficient wire protocol
b.) reach more people than Real
c.) make the interface intuitive and able to be skinned / themed
d.) do this in less time
Real is dying (search
Another equally valid motivation is the desire to apply technologies you learn "on the job" to hobbies you enjoy "off the job." If you can connect the positive feedback loop, there's no limit to what you can do.
For example...
During the day I work on a web services project that primarily uses Java as the implementation language. We catalog earth science metadata. I've learned an awful lot about web services because of what I do on the job, but it's unfortunately all in Java.
I'm also interested in meteorology. So at night I tinker around with my weather station console using perl and python (and some Java). Because of my exposure to web services at work, I thought it would be fun to publish my weather data using web services at home. But, I don't like Java too much. So begins the process of learning and patching the perl/python web service libs to support more functionality.
Where this becomes interesting is that recently at work we had to stand up some services in a really short amount of time. Java would've taken too much time and would've been very difficult to manage. Drawing upon what I learned "off the job" on my weather project, I was able to stand up the services in python and perl in a very short period of time. Being able to focus 8 hours a day on perl/python web services afforded me the time to make more patches to the library. More patches created more possibilities using the web services library.
I'd then go home, and exploit those patches in my weather project. This opened up new potentials for my weather project, which helped me to push out the envelope a little bit further. Go back to work the next day, apply what I did in my weather project the night before. Find more stuff to patch in the open source libs, and implement it. Go home, exploit the patches I made during the day.
Open source can be used as a way to one-up what you worked on at work during the day, and can allow developers to apply technologies they find interesting (at work) to domains they are interested in (at home). It is the application of 8 hours of research in a lab (work) to the real world (your open source project). It not only helps you grow technologically, but it can make you happier at work, as you think of all the different things you can implement tonight on your open source project as a result of what you're learning technologically today at work.
What is it about testers and their negative reactions to developers writing tests? Is it out of fear of job security? I don't understand why so many testers frown upon or discard tests written by developers as worthless, or second rate, to the tests that they have written. Indeed, many times what accompanies test dismissal is the comment of "Developers don't know how to test software." Nevermind the lack of supporting details to back up this broad generalization.
;-)).
What to me is so strikingly insane is that at the most primitive levels, testers write tests. What kinds of tests they write vary in size, scope and purpose. Developers, through unit tests, are technically doing part of the the tester's job. They produce tests! Sure, they are unit tests, but they are still valuable from the standpoint of software verification. Even if a tester walks away from them with simply a better understanding of how the software is put together, does that not make them valuable or important?
Too many times do testers toss away unit tests as worthless (or in Moses' case "hackish") simply because they were not written by a tester. Tell me what qualifications you must have to be a tester and to write tests. What are your criteria for considering a test valid or valuable? Now tell me how I can run the litmus test against my test to see if it passes what you consider to be the qualifications for inclusion into a suite of tests.
Were the best interests of the project (not the individual) ranked at the top of the importance list, I would expect testers to gleefully accept developer unit tests. Not only do they show accuracy in the software, but they more importantly demonstrate a developer's willingness to test and prove functionality. "Here's my code, it implements requirements X, Y, and Z, and here are the unit tests that demonstrate the functionality." Given that, a tester needs to tie together a high level interaction test or execute the regression tests. But the developer has gone a long way to help out the tester, and more times than not the tester pushes back with some assinine comment like "developers don't know how to write tests."
Successful software teams are not like the 4x2 tetris block, where the design team hands off UML to the developers to implement, who then hand off the code in an assembled version to the testers to verify. Successful software teams are a coagulation of the + tetris blocks where developers perform some requirements analysis and testing while at the same time coding. Testers pick up some system administration. And system administrators do some testing and even development. This type of cross-pollinated structure on a team keeps code velocity high, job competition to a minimum, and leads to higher overall satisfaction (generally speaking, of course
Your view of unit tests as hacks without the proper overall test plan shows your inflexibility to cohabitate with developers willing to test on your project. Archaeic views like this usually lead to unsuccessful projects. Take a moment to look back over your resume and reflect on the various software projects you've worked on. Ask yourself what developement environment existed, and if the project was successful. My guess is you'll notice a pattern.
Here's a slightly mischievous, perhaps sleazy, method of avoiding out-and-out copying of proprietary commercial code from one company to another: Make as much of it as open source as possible.
For example, say you're developing a set of components that will call each other using SOAP. You know that the components will be implemented in different languages, so you'll need to perform an interoperability study to make sure that everything works properly. There certainly isn't anything proprietary, or commercially viable from an exercise such as this. So talk to your boss about doing it as an open source experiment.
Set up a project somewhere, and try to dump as much "study work" (these can be stubbed out prototypes) into it as possible. Then, being open source, you can use the prototypes as reference material when you move on to another company.
In our project I was able to perform all of our interop work (e.g. Can perl call python services? Can java call perl services?) in an open source project. There was tremendous knowledge gain as a result, and the results are portable across employers. The only thing you have to make sure you do is not violate any company rules for release of source code. Make a point to say that you're not releasing any existing source code, you're writing *new* prototype source code in an open manner and that nothing proprietary or secret exists in said prototype code.
Doing so allows both parties to achieve their goals: you get to keep a reference guide for future projects, and your company gets to keep it's secret code secret.
There are numerous licenses in existence that would allow Sun to maintain their closed source product that probably would not be against RedHat policy.
.so file into your browser (rarely do the already compiled .so files line up with your browser version), put out a dozen or so different sub releases (JDK 1.4.2_03 build 13? come on...), and then watch with confused looks on their faces as Flash takes over the world of client side GUI development.
I think the crux of the issue with RedHat is that:
a.) Sun wants you to download Java only from Sun
b.) RedHat wants to redistribute Java via the RedHat end user license.
The two don't have to be mutually exclusive. I don't understand why Sun can't just let "other people" (RedHat, FreeBSD, etc) distributed their binary code without checking in at Sun.com first.
As a java developer who earns an income based upon Java's success, I really want to see Java succeed on the desktop because it opens up more development avenues for me and other java developers. And I think that Sun has an interest in java succeeding on the desktop as well (their Java Desktop would seem to indicate this). With technologies like Flash that are so nice looking, so easy to install, and lots of times already integrated on your platform - you would think that Sun would be doing __everything_in_its_power__ to help foster the growth of java on the desktop.
I would think Java would be out there lobbying Dell and Compaq pumping them to install WebStart on their desktops. Or put in an up-to-date JRE into IE. Or . . . put in a stinking applet viewer into the Mozilla that ships with the Linux distro most commodity users install.
But they don't. Instead they sit back, come up with a dozen or so mime-types that represent a Java Applet, make it prohibitively difficult to install the correct
Come on Sun. Wake up! I want java to succeed on the desktop as much as you do. You guys clearly haven't figured out how to make Java pervasive - maybe us assclowns at home can figure it out. Just give up the EULA rights to Java so that one of us can figure out how to do, patch it into a vanilla distro (like Fedora), and let you reach the end users you've failed to reach since you came up with applets years ago.
There's nothing like knowing a solvable problem exists that you can't even begin to troubleshoot because some asshat lawyer somewhere wants you to sign their EULA instead of the one from another company (which is frequently the same stinking one).
One of the big problems with Java is the license. Here are some issues that real people have faced:
1.) RedHat couldn't put a JVM in their desktop OS w/out including the Java license in anaconda and having the end user agree to it at install time. As a result, RedHat couldn't set up Netscape and Mozilla to run Java applets seamlessly and out of the box.
2.) FreeBSD couldn't include Sun's JDK in the ports tree out-of-the-box. An admin pays $$$ for cut CDs or spends time to download ISOs so that they don't have to do a network install. When they find go to build Java on FreeBSD they are told by the ports tree to go "agree to Sun's license and download the JDK from http://java.sun.com/blah/blah/blah". Not only is it annoying to have to download an extra component that isn't included on the ISO, it leaves a poor taste in the admins mouth for Java. And come on - admins are the last people developers want to irritate.
I can understand Sun's position with not open sourcing Java. Although relatively uninformed on the topic, I don't see any prevailing reason to make it open source - there are open source implementations of the JDK other than Sun's - go with them. But for cripes sake change the farking license.
It is a sad sad statement that I, as an enterprise java developer of 6 years, am unable to get applets to work appropriately on my Linux desktop.
Why do I have to register if the content is "free"?
Excuse me while I purge all of this spam....
No wait, it's not free after all.
I've been reading the responses to this thread most of the afternoon (on and off) and have not come across a pro-cable post by anyone.
I think that says a lot.
On item #2:
I found that the cable tuner boxes *always* lagged behind the quickness of satellite tuners. I'd press a channel and then have to wait for nearly 2 seconds between when TiVo hit the "done" signal for the digital cable box.
Unacceptable.
This could not be more true. The guide for Comcast cable (no matter where I go) is horrific. That sleezy gold background, with FF0000 on top of 0000FF brings me to tears - do they honestly believe that the brightest blue next to the brightest red is a *good* idea?!
The usability is poor, the font looks like something I produced on Apple's Paint Shop Pro back in 1992, and the ads are annoying.
Compare that to a TiVo or satellite guide, which often times features smoother more legible fonts, a transparent background (allowing you to view your current program while browsing the guide for other programs), allows you to go forward and back in time, features more than 5 channels per page, and supports page up and down - and I don't imagine why anyone would go with cable.
How about USB2.0?? Make sure you check the label for "High Speed" to make sure it's not a hokey 11Mbps.
Sickening....
This is not unlike digital still cameras.
Have you been to Best Buy lately? You can purchase a 5 MP camera for $300. How can that be?! Because the camera delivers an effective rating of only 2.0 MP. Somehow the manufacturers are able to tout their product as a 5 MP camera.
What's going on here is the manufacturers recognize that consumers of electronics are sensitive to product numbers. When was the last time you heard of someone walking into Sears and purchasing a dishwasher because it has an R52JU actuator servo? Never. But, how many times have you heard of someone walking into Best Buy and purchase PC133 or PC2100 memory? All the time.
HP and Toshiba know that laptop purchases are sensitive to owning a Radeon 9200 (just like how digital camera makers know that purchasers are sensitive to owning a 5MP camera). It's not surprising at all the manufacturer is willing to futz with the model number to deceive the consumer.
The real question is: what are you going to do about it?
Moreover, the NASA of today is not the NASA of the 60s. Today's NASA is a politically correct beurocracy, where they are held to equal opportunity hirings. Therein lies the problem: going to space and back is *not* something a random cross section of the country's population is capable of realizing. Going to space and back is something that only the cream of the crop can do. But since that doesn't give every hillbilly redneck a chance, it's not fair, and what's not fair is changed.
NASAs not going to change unless society changes and people own up to not being up to a task.
I work for a NASA contractor. We put in a purchase order recently, and after waiting 2 - 3 months (this was for a $12000 purchase), we recently found out that we'll have to wait another couple of months. Turns out the procurement system for *all of* NASA only uses 4 digit ids for procurement. 4 digit ids?! What beatnick came up with that lame idea?
We need to privatize space flight so that companies can be formed that only hire the cream of the crop. Not this lowest common denominator bullshit - it's led to both the Challenger and the Columbia going Tango Uniform.
-c
I have a possible solution that I believe fits both camps of convenience and security.
For starters, don't change SMTP. Leave it be.
Adopt the follow standard at the mail user agent level:
Mail encrypted using your public key is "trusted", and will appear in your unfiltered INBOX. You can distributed your public key to whomever you see fit, and when they send you mail you'll automatically get it.
Mail not encrypted using your public key is subject to the filtering methods that exist for detecting spam (bogofilter, spambayes, spamassasin, etc). Periodically scan your non-whitelist email from time to time to see if anything is in there that you are interested in. If so, send that fellow your public key.
It's not a perfect solution, but it does address some of the problems we currently have.