I am a Java developer and I have worked for a commercial CMS vendor. Essentially, the low end of the market is dominated by php for obvious reasons: it's easy to get started and basically any hosting will do since it will run php out of the box. Also that stuff is pretty good: I'm perfectly happy with wordpress for my low end needs.
On the other hand with Java there are no cheap hosting solutions. Basically it requires a a dedicated server solution which will set you back 50-100 $ per month minimum. There are shared hosting facilities but they are still more expensive and don't really give you enough control. People with low end needs won't even consider that as an option, and they shouldn't.
However, there's also such a thing as the high end of the market. Basically php is just one of the many options there and as far as I can see it far from dominates that market. A lot of interesting things are happening in the Java enterprise scene: there is standardization of content repositories (JSR 170) with several commercial and OSS implementations available; there is the portlet standard, which is basically the backbone of many commercial portal servers; there are lots of options for implementing web UI stuff; there is adoption of the cool rails stuff with both groovy and jruby on rails being worked on; etc. Essentially Java is one gigantic toolkit for building web applications now.
Bottom line is that if you are expecting to spend a few thousand dollars on hosting (yearly) and have a budget of say 20K+ for building the web site, you are in the high end of the market. You will want some guarantees about your site not collapsing when a few million people decide to drop by; you'll probably have some old content to migrate and some non trivial functionality that you'd like to have. Chances are that you'll end up using Java. Or rather, chances are that you decide not to reinvent the wheel and use the services of some professional CMS companies.
Good comments. I'm also a bit annoyed with the conservative ignorance being displayed in this thread. I've been reading about openid a few weeks ago. Essentially the idea is quite elegant and minimalistic (something that should appeal to the unix crowd here) unlike most of the federated identity crap from Sun and MS.
The basic idea is to have a url as your login name + a protocol to verify whether the person claiming to be that identity is who he claims he is (authentication) with the server that owns the openid url. You can do authorization on both sides. One of the most basic things you can do is grant or refuse a site the permission to verify your identity. So there's no stealing your personal details without your explicit permission. Also since the protocol is distributed, very much like email, you can host the openid server yourself if you want to.
What would happen if you'd try to login to an openid enabled slashdot? Well as a first step, you'd provide your openid url to slashdot (without password). Slashdot would then contact the server where the openid url comes from and ask it to confirm the identity. Assuming this is the first time you visit slashdot and that you are already logged into your openid account, you will be redirected to the the openid site and it will ask you if you want to give slashdot permission to authenticate you and also what personal data to expose to slashdot. Only if you give those permissions, slashdot will get an affirmative from the openid server. Next time you visit slashdot the process can be automated because you have already given slashdot the right permissions.
What benefits are in all this: - slashdot never sees your password - you only provide your password to your openid server (and of course you should change it on a regular basis as well). - you have to grant slashdot the permission to authenticate you (and you can of course revoke this right as well). - similarly you can grant the permission to use parts of your personal data (email, public pgp key, name, addresses, phonenumbers,...): openid gives you fine grained control over your personal data. - these data items are centrally managed so you only have to change them once instead of updating your dozens of accounts. - your identity + personal data is managed by a server you trust (or your own openid server if you don't trust anyone). - should your identity be stolen, you have a central place to go to block the whole thing and change your password. At this point, you'll probably also be very interested in any server logs detailing what sites attempted to authenticate your stolen identity and ip numbers of computers who were claiming to be you.
Most of these features you don't get with the default slashdot login.
Then of course things can be layered on top of this. For example, a site asking for credentials could be required to provide proper certificates. And the openid server could warn users about potential phishing attempts by comparing the authenticating site automatically to a list of malicious sites; etc. To me that is a lot better than having a few dozen accounts on untrusted sites, all with a weak password (often the same too) and stupid endusers in charge of trust decisions they only half understand.
And of course there are similar advantages for sites verifying the identity with the openid server. They can check certificates of the authenticating server; compare the server address to a list of malicious identity servers and have a central point to complain in case of abuse.
The widespread adoption of a standardized version of this protocol could be a real step forward for the internet and make it a more secure place than todays internet.
The real problem is that very few teachers or professors have relevant experience when it comes to software engineering. Most of them have spent their entire professional life in the academic world where all they see is flexible deadlines and toy systems of at most 1 kloc. Most of them don't really understand the dynamics of medium to large software projects (100 kloc+).
Sadly software engineering education is still based on the model of master-apprentice. When people leave university, they basically know nothing relevant. They have no experience with the relevant tools and practically no exposure to the relevant library. If you are lucky they had a decent introduction to languages and algorithms. Probably they are really good at building parsers that nobody needs and optimizing data-structures that they shouldn't be reinventing in the first place. Beware of small consultancy startups with young software engineers. Most likely your project is their first real world experience.
There's all sorts of analogies you can make. Some are not so appropriate. But a key thing to understand is that the response to a perceived threat can actually be more of a problem than the threat itself. In the case of terror and 9/11, the response has been a major disruption of power balance in the middle east. It's hard to estimate exactly how many died, whose fault that was and whether these people had it coming or not. Fact remains that that number is many times the number of people killed on 9/11. Also some high ranked politicians and army people are actually voicing the opinion that terror threat actually got worse due to the invasion of Iraq. And of course even the number of US casualties in the war on terror is set to exceed the number of lives lost during 9/11 pretty soon.
Another interesting response to a threat is gun ownership (in response to perceived threat from crime). Many people die each year from accidents with guns bought for 'protection'. People end up accidentally shooting themselves, their relatives or innocent people who happen to be in the wrong place instead of the hypothetical burglar for which the gun was bought. There's actually people arming themselves to the teeth to 'protect' themselves from perceived threats without realizing that them being armed to the teeth is an accident waiting to happen. News reports of mentally unstable people (highschool kids in some cases) using legally purchased guns (plural!) are all to common in the US. It's hardly news anymore unless the killer manages to kill a few people. Also because there are so many guns, criminals are pretty much guaranteed to be armed. I'd probably want a gun if I were living in the US just because of that:-).
Of course in computer security related matters, there's such interesting things as people losing unencrypted USB sticks with important files because their sysadmins made it impossible/difficult/inconvenient to transfer files using e.g. email or IM between their laptops. Lock down a system properly and your users will start being creative to find ways around your security measures. I've seen this so many time: oh can I borrow your usb stick to pass my confidential powerpoint slides to that guy over there? My company wastes vast amounts of money on laptop security. The measures have a severe impact on performance so everybody needs rediculously fast laptops just to do ordinary office stuff.
My thoughts exactly. I apply for jobs on invitation only and usually the job vacancy is tailored to my CV. The few times I got involved with recruiters have been bad experiences.
The job interview is there for me to decide whether I want the job. I always go into a job interview with that attitude (which btw is a great way to get yourself hired). That may sound arrogant but that is the attitude you should expect from qualified people. They know they are good, others know they are good and if you do your homework you don't have to bother spending much time figuring out how good they are. By the time you are talking to them over a phone you should already be 95% sure you really want to hire the person in question. The problem then becomes convincing them to do that.
Job boards are there for people who for some reason have trouble getting invited to apply for jobs when they want another one (or worse, don't currently have one). They are a useful tool but by definition not the place to look for the best. It's a good place to find inexperienced junior SEs. Beware of people advertising their long career on a job board because they're there for reason!
So, some advice to companies looking to hire the best: - Don't expect people to come to you, they won't. Also they won't read your job vacancy descriptions or kindly present themselves to your HR staff. - Use your network to find potentially interesting candidates and if at all possible contact them through people they know and trust - Assume that they have nice jobs and are not really looking for a job: i.e. do not approach them by phoning them during office hours - Don't expect them to be enthusiastic when you approach them, you will need to sell your job to get the skills you need - Be prepared and don't waste their time with non skill matching offers (i.e. don't waste people's time) - Be specific about what you want from them and what you are offering in return. - Be specific about the fact that you intent to hire them (assuming that you are by this point). - Present your HR department as what it is: the people you have for dealing with boring formalities and not an obstacle for getting a job.
I'm posting this because I'm contacted frequently by stupid recruiters insisting on basically ignoring all of this advice. I usually turn them down before they even have a chance to offer me a job.
Upgrading the jvm does not cost that much. It's a free download and the upgrade is backwards compatible. On top of that 1.3 is now pretty much unsupported stuff and the 1.4.2 version performs a little better and has lots of nice improvements related to scalability. I'd recommend to go straight to the latest 1.5.0 runtime unless you have some very specific technical reason not to do so. And even then you should consider fixing it rather than not moving to 1.5. You can of course choose not to use the new language features for the moment (compile target="1.4").
I can understand that people are more reluctant to upgrade the application server but even so, j2ee 1.4 was mostly an incremental improvement over 1.3. Most of it was pretty good improvements and refinements.
It's not about things being broken and whether or not to fix things them but about making developers use old stuff for building new stuff. You're right if the systems are not being maintained anymore. But in reality people will be doing lots of maintenance on these systems. Statistics indicate that 60% of development cost is maintenance and I suspect J2EE systems are no different.
JEE 5 is a different story it's a major architectural change. Application server vendors are still lagging with implementations. I've used the incomplete jboss implementation that comes with jboss 4.0.4. It's nice and saved me a lot of time but the documentation still sucks and there's all sorts of little things that must be done just right to make JBoss do all the deployment magic. When it works it is great though but it's not production ready yet and the implementation is incomplete (even though it covers the more important bits and pieces of the spec now).
A lot is wrong with nepotism and corruption of which this kind of behavior is a symptom. Of course the EU is exactly not free from that either. Using political or economic pressures to influence a legal process in general is not a good thing. In both the EU and the US the legal framework that is meant to keep the political and legal word separate is eroding rapidly. Separation of church, state and law is a joke these days but it used to be a good idea.
The problem with lens technology is that there don't seem to be that much major breakthroughs anymore. Sensor technology on the other hand continues to improve rapidly. So, the main point of a next gen SLR will be the sensor, not the lens. You are probably right that increases in the number of pixels will not be the most relevant sensor improvements though. Being able to shoot with ISO 3200 or even more sensitive values without much noise will be features to look forward to. Right now pushing most cameras beyond 400-800 is already too much. Of course noise is less of an issue when you are shooting at 50 MPixel, you can afford to run elaborate noise canceling algorithms without too much loss in details with that kind of resolution.
Agreed, articles should go through some lifecycle where, as article quality increases, it should become harder to edit the article. Articles would start out editable for everyone and at some point, it would reach a stable state where approval of key individuals would be needed to publish further changes.
For example some articles like the one on Pythagoras are quite elaborate, extensive and by now probably more or less stable. There might still be valid reasons for making changes but probably reviewing such changes would be preferable to making them and then having others fix the damage later.
A nice model would be to have a built in delay (2 days) in the publishing + notification and the ability to object/ammend the change. So a user would add 'math suxors' to the pythagoras article and all the interested people in this aricle (previous authors?) would have 2 days to ammend/delete the change. After 2 days the change is published automatically unless somebody objected. In this case, the change would never be published.
You don't want this model for all articles, just for important articles (many hits or many refs to them) and stable articles. Both of these can be identified automatically. Ownership of articles would default to whomever did any changes to the article previously. Any disagreement with a change would prevent the change from being published until the conflict is resolved either by friendly discussion between reviewer and author or by normal wikipedia conflict resolution processes (whatever those may be right now).
Selling books in the education market is highly profitable business. Let me rephrase that: publisher profits in the education market are financed through government sponsorships (e.g. research grants); money intended for education (e.g. scholarships or parent contributions) and money earned by students in various jobs when they should be studying. If that's not good enough: students are more or less required to buy the books (provided you get teachers to endorse them). Vast amounts of money intended for education flow more or less directly to the publishers. Under many governments, that includes substantial portions of the tax money you pay.
Essentially the problem is the same as in the scientific article publishing business: authors see little or none of this revenue. Essentially, all the profit is for the publisher. If your name is Andrew Tanenbaum, well maybe you do get a nice salary from the hundreds of thousands of people buying your books. But otherwise, the fees do not come close to paying for the time invested in the books. These books tend to be printed in small editions of a few tens of thousands copies at best (production cost a few dollars each). The point is, authors mostly are not doing this for the money but for the honor (including having their book printed by a well known publisher).
The printing business made a lot of sense when distributing dead trees was the only means of distributing information, other than by re-enacting it in front of an audience (quite normal until the invention of book printing). Nowadays, books are all about convenience and having glossy covers on your shelf. The convenience consists mostly of having better contrast and the ability to 'scribble' in them. The shelf factor of many books is arguably more important than the actual content. Many books are never even read cover to cover!
The solution is simple: get the publishers out of the loop and distribute the books electronically under for example the creative commons license. For the price of a normal book you can easily finance printing the entire book on glossy paper with a really expensive inkjet printer in full color, should you wish to do so. Of course putting a bunch of laser print copies through a high volume copy machine is much faster and cheaper. And for some, reading stuff from a screen works just fine (you don't print slashdot 20 times per day, do you?).
There would of course need to be some infrastructure for editing, reviewing and ranking books (e.g. by references to it or endorsements by people/universities/schools). That should be a relatively simple problem to solve and I don't see the need for involvement of for profit publisher businesses in this. Additional value could be provided in the form of reader forums/blogs, regular updates to the content, reader provided exercises, references, etc.
That is incorrect. Some of these tools: e.g. Findbugs, pmd and lint4j are not about code style at all. Instead they look for real antipatterns and situations that usually indicate a bug. For example these tools will identify potential deadlock problems, obviously wrong uses of the synchronized keyword, draw your attention to null dereferences (npe at run time), streams that you forgot to close properly (i.e. in a finally block), etc. Some of these things can be quite hard to find in code and will slip through manual reviews. All of these tools come with hundreds of preconfigured rules and more are added with each release.
Some of the warnings can be categorized as not really relevant (and can be optionally disabled in the tool configuration) but most of the things these tools detect are things that you probably want to fix if you know about the problem. Sure these tools don't find all problems but they do find several types of important problems if they exist in your code 100% of the time. Personally, I'd like to know if some jerk forgot to close the database connection before I put the code on a production server. Findbugs gives me that information.
I wouldn't call running across the field with a inflated device that is does not even resemble a spherical shape football. It seems neither feet (except for the running of course) nor balls are involved.
I don't know about your definition of interesting but most of the java stuff I work with on a daily basis works unmodified on the three big desktop platforms (and probably everything else that runs java 1.5) and does so for the ten or so years I've been developing Java. This stuff combined is probably several million lines of code. Also all of the stuff I write in Java is 100% crossplatform, barring the odd jdk bug that somehow fell through the 60000 or so unit tests they unleash on the jdk nowadays (just a disclaimer, can't recall ever encountering one). In my previous company we developed on windows, had staging servers running linux and deployed more or less blindly to our customer sites running windows 2000, 2003, various flavours of linux and even some sun machines. Worked every time. Portability was never an issue. Not even having to test for portability issues is a huge time and cost saver.
A good example of a portable J2ME app is opera mini which exists in only two variants the both of which work across pretty much all java capable phones except maybe for the really crappy ones, such as your Palm based one (blame Palm, not Sun). J2ME is a modular specification which unfortunately leads to the interesting situation that the more of the modules your app uses the less portable it becomes. Pretty much all of the modules are optional and with MIDP 1.0 many vendors added loads of vendor specific APIs as well. Many applications written for that mixed bag of standard and non standard extensions are not portable.
MIDP 2.0 mostly removes the need for vendor specific APIs (though many vendors still ship them). Upcoming MIDP 3.0 is even better apparently. of course many games need to make assumptions about device specifics (e.g. screen size, number of colours, keyboard layout) which unfortunately leads to many portability issues. These problems are hard to solve and currently J2ME seems the best solution the market has come up with. Most device specific binaries of J2ME apps merely include some minor modifications, optimizations and packaging. I agree that testing for all that is a major PITA for developers. If you have a better solution that works for non trivial applications across the thousands of different brands and types of mobile phones, get some venture capital and get rich!
I don't know, nobody seems to have bothered spending much time thinking about that. I think the past ten years have shown that design by committee is not the way to solve the problem in a satisfying way.
I'm not claiming there is an alternative just complaining about the lack of one. To me CSS seems awfully limiting. Some of the issues are being addressed in CSS3 so on paper that would be a nice improvement.
I'm not claiming web sites use flash a lot, just that it is the technology of choice for graphics designers. Reality forces them to downgrade to CSS+javascript+html in most real life situations but in terms of layout flexibility flash (or something similarly capable) is what they really want to use.
I used to care. Now I don't any more. I consider the whole batch of so called standards collectively known as the web pretty primitive and backwards. CSS is a horrible standard not suitable for defining moderately complicated layouts (or even certain trivial ones). It's not the best we've got it's just something put together in a hurry independently from the (surprise!) independently evolving implementations, ten years ago. Attempts to steer browser development through forward defining new revisions of this standards have largely failed. And browser developers after spending most of the last decade interpreting CSS 2 seem to slowly settle on an interpretation of a significant subset of this standard from 1999 (or was it even earlier)?. CSS3 can now safely considered to be as dead as a doornail with browser developers cherry picking the little bitts and pieces that are more or less finalized.
Acid2 is not about CSS compliance but about supporting the documented ambiguities in the standard correctly (many undocumented ones remain). These ambiguities include weird parser behaviour, browser quirksmode hacks for non standard pages etc. In short, it test the browsers ability to fuck up the rendering in a consistent way. Of course the biggest fuck up of them all (IE) fails the test so the test is pretty much worthless in practice. It even fails rendering incorrectly:-).
Then there is HTML which evolved from a naive attempt to capture semantics of certain documents by Tim Berners Lee to a slightly worse specification (HTML 4.x) which isn't really good for anything it is designed to do (ranging from layout features to representing document semantics). The successors in the form of XHTML 1.x and 2.x drop the layout stuff (which sucked anyway) and tried to preserve most of the flawed semantics whilst adding new constructs and increasing complexity so much nobody really understands it. Market apathy has ensured that these xhtml standards never moved out of the lab. XHTML documents actually served up as application/xml (alledgedly the correct way to serve them up) are extremely rare although well formed versions of html 4.x are now commonly served up as xhtml 1.0 transitional (or even strict). Other than forcing the browser into a somewhat better defined way of rendering, this has little effect in terms of layout features compared to html 4.x.
Let me see what else have we got? There's crappy SVG which slowly seems to replace gifs for sclable icons on some systems and also leads a double life as a poor mans graphics exchange format. There's the hopelessly underpowered javascript language and the accompanying APIs (DOM *shudder*). There's MATHML which remains ever popular in very small niches. Most of the mentioned technologies lead a double life in the form of how they are supposed to work and how they actually work in practice. Pragmatic web developers just copy paste and adapt what works and ignore the rest. The smarter ones build up some knowledge of how things are supposed to work and where the bugs are for each implementation. All the graphics designers seem to have standardized on non standard flash. With standards nazis mainly telling them not to use flash, instead of providing an alternative, this is unlikely to change in the forseeable future.
But as said, I no longer care that much. Increasingly tools take care of generating the exotic hacks to make it all work. Handcoding something like gmail would probably drive programmers mad, which is why the nice google people embedded the difficult stuff in a nice library so they can focus on application functionality.
I've used lint4j, pmd, checstyle and indeed findbugs. These tools are very useful. The biggest problem is finding the time to fix the issues. It's tempting to skip the minor issues but then this is where you need to be strong.
I'd recommend that serious java developers integrate the above mentioned tools into their nightly builds and treat the identified issues as real bugs.
The reason I'm recommending subversion is because I strongly believe that development artifacts should be kept as close to the source code as possible (so when you branch or tag these artifacts are part of the operation instead of out of date binary blobs on some network drive). Since we are talking about functional specifications here that means storing them in a source repository and as far as I can see subversion is the best option. It supports efficient storage of binary files; easy integration with windows explorer; easy esposure through an intranet or even over internet via ssh or https; integration with webdav etc.
Do not use cvs. Period. There are no use cases left where cvs is better than subversion. Even the tooling now is comparable or better for subversion (e.g. tortoisesvn is much nicer than tortoisecvs) so the legacy tooling excuse for using cvs is no longer valid.
Or more general, virtualizing allows you to do dynamic optimizations in the interpretation of whatever virtualized API you are using. This how dynamically compiled Java can outperform statically compiled C for selected code fragments. This is also how HP showed a C vm outperforming compiled C on the same machine for selected programs. The vm could do optimizations at run time a compiler couldn't possibly do before run-time.
Native means performing according to whatever (naive) assumptions the compiler or programmer has to make about the run-time environment. Disk access is easy when your program is the only one talking to the drive. It's a different matter when there's hundreds of processes and thousands of threads from other programs are doing the same. That's why operating systems virtualize disk access and disks in turn also virtualize raw access to the disk platters (so your OS does not actually tell the disk when and how to position the heads). Disk performance would really suck without virtualization. So would writing any app that uses disks.
But still he is wrong. Understandable, he's never liked Java and there were a lot of public statements/announcements last week from SUN. One of them indeed was about the license change for distributing binaries. Another wasn't so much an announcement but a confirmation from the newly appointed CEO that SUN now intends to make java available as open source. This in response to questions from the audience on this topic. This has since been re-confirmed by him and several others inside SUN. Sure, that still not very specific with respect to what, when and how. But it is different from the simple 'no way' that Scott Mc Neally has been answering to this question for years.
If your businesslogic breaks when you change the site layout then embedding HTML in your business logic clearly was a bad idea. Doing so gets you up and running soon but you pay the price later when doing maintenance.
Putting some time and effort in separating logic and presentation is not a novelty. The MVC pattern dates from the seventies. The n-tier server architecture was invented shortly thereafter. These two are now well accepted architectures for separating logic and presentation.
As for performance. Code that mixes everything together tends to be naive in multiple ways, including performance, security, extensibility, etc. Optimizing performance generally requires using caching, pooling and other types of strategies. These are hard to retrofit in monolithic single tier systems. Again there's no absolute truth here: you just may be the genius that gets it right in one go.
So it all depends on the question are you the guy who's doing the maintenance and/or will you be there when the shit hits the fan when somebody else tries to do it for you. If so, you are probably better off doing a proper job. On the other hand, out of control IT projects are a great way to milk stupid customers. Many IT businesses have built their empire on that kind of incompetence and billions of dollars still change hands annually for software projects that are over time, over budget and ultimately disappointing.
This is the first comment in this thread to contribute something sensible. It is my personal opinion (based on observations in practice) that C based systems hit a hard ceiling in terms of managability around 3-5 million lines of code. Above that nobody can be found with a good enough mental map of the system to engineer it properly. This is not a hard limit, there's several ways to stretch it a bit. None of these ways involve technology: they are about process, discipline and engineering practice. With that in place (expensive) you can grow a few million lines of code more. Currently the largests systems around are around 100 million lines of code. These are complex beasts requiring the constant attention of thousands of software engineers. They take years to release and are only allowed to continue to exist because replacing them effectively is killing the company.
The C language provides so many vectors of severe stability and security issues that just isn't funny. Most of these technical issues have well working, tested and proven solutions in other programming languages. Shared memory space is only a problem if the compiler/run-time environment allows you to abuse it. Many programming environments exist that allow you to safely share data. Doing that from multiple threads is quite safe as well provided you understand what you are doing. Most problems in that area are related not to memory corruption but deadlock, race conditions, etc.
It's of course a non issue entirely in most scripting languages or virtual machine based languages. But statically compiled languages with similar performance characteristics to C exist as well. So I agree, C was an expensive mistake. Each crash/bsod/security leak/kernel panic/whatever, we pay the price.
So essentially users will be subsidizing the expensive, redundant and obsolete physical distribution chain involving (re)production of the discs, shipping, marketing, retailing and margins of all the people involved in all of the previous. Sounds like a great deal. Wake me up when prices drop to a more realistic level involving only content production cost + marketing + hosting (should be negligable using bittorrent).
Besides, I'm not at all interested in producer verticals. I want to buy on a horizontal market with multiple sources of content where competition happens based on price and quality of the content. I guess this is too much to expect from companies who are essentially entirely optional in a digital world and well aware of that.
In economic terms the problem of production and consumption is extremely simple. There's this notion of the value adding chain. Essentially that means that each step in the process is about making output more valuable then input (e.g. trees->wood->chair). Added value is something you can build a business on. The movie industries current idea of ading value is doing everything the old way, actually removing value (i.e. the physical media + consumer freedom) and then asking the same inflated price as before.
The market opportunity here is huge. With a distribution model that is essentially close to free, sales are pure profit. Maximizing the volume/revenue curve is the trick. Maintaining old prices, will ensure that volume stays limited to those few nuts who don't care about money, the dvd and just want to see the movie now. Not a big growth market. Then there's people like me who generally don't waste 20 dollars on a dvd unless they really want to see it (in my case, rarely). There's plenty of movies in the past few years that I have not seen and that I wouldn't mind seeing. I'd gladly pay a small fee for convenience here. In other words, I represent a market opportunity. If 20 people pay 2$ that is the same amount of revenue you get from 2 people buying the same movie for 20$. My guess is that there are a whole lot more people willing to spend 2$ on a movie than there are willing to spend 20$ on a movie (especially bad movies, something that hollywood specializes in). This in short is the iTunes businessmodel: people are paying 1$/song for stuff that is pretty hard to find in regular stores. That's pure profit (aside from the music industry tax).
Of the 50 million+ lines of code that make up windows, relatively few are in the kernel. Also most security bugs that are being found have no direct relation to kernel level code (e.g. many viruses do not even require admin rights to propagate and do their damage). Similarly, linux and unix security bugs are mostly found in user mode stuff like bind or openssh. Microkernels do little or nothing for such security related matters. As far as stability is concerned, both windows and linux tend to be quite stable these days except for the occasional crappy driver. Hardware stability is a much bigger issue (e.g. overheating components). The benefits of microkernels do exist but they solve only a small part of the stability and security issues experienced by users.
Rather than replacing current OS kernels by microkernels (which would take years if not decades), the soltution is to simply keep refactoring them. Both the linux kernel and the windows kernel are evolving and both include facilities for protecting memory; loading some drivers in user space; etc. I'm sure kernel developers have not yet run out of tricks to improve them further.
Slashdot Mirror
I am a Java developer and I have worked for a commercial CMS vendor. Essentially, the low end of the market is dominated by php for obvious reasons: it's easy to get started and basically any hosting will do since it will run php out of the box. Also that stuff is pretty good: I'm perfectly happy with wordpress for my low end needs.
On the other hand with Java there are no cheap hosting solutions. Basically it requires a a dedicated server solution which will set you back 50-100 $ per month minimum. There are shared hosting facilities but they are still more expensive and don't really give you enough control. People with low end needs won't even consider that as an option, and they shouldn't.
However, there's also such a thing as the high end of the market. Basically php is just one of the many options there and as far as I can see it far from dominates that market. A lot of interesting things are happening in the Java enterprise scene: there is standardization of content repositories (JSR 170) with several commercial and OSS implementations available; there is the portlet standard, which is basically the backbone of many commercial portal servers; there are lots of options for implementing web UI stuff; there is adoption of the cool rails stuff with both groovy and jruby on rails being worked on; etc. Essentially Java is one gigantic toolkit for building web applications now.
Bottom line is that if you are expecting to spend a few thousand dollars on hosting (yearly) and have a budget of say 20K+ for building the web site, you are in the high end of the market. You will want some guarantees about your site not collapsing when a few million people decide to drop by; you'll probably have some old content to migrate and some non trivial functionality that you'd like to have. Chances are that you'll end up using Java. Or rather, chances are that you decide not to reinvent the wheel and use the services of some professional CMS companies.
Good comments. I'm also a bit annoyed with the conservative ignorance being displayed in this thread. I've been reading about openid a few weeks ago. Essentially the idea is quite elegant and minimalistic (something that should appeal to the unix crowd here) unlike most of the federated identity crap from Sun and MS.
...): openid gives you fine grained control over your personal data.
The basic idea is to have a url as your login name + a protocol to verify whether the person claiming to be that identity is who he claims he is (authentication) with the server that owns the openid url. You can do authorization on both sides. One of the most basic things you can do is grant or refuse a site the permission to verify your identity. So there's no stealing your personal details without your explicit permission. Also since the protocol is distributed, very much like email, you can host the openid server yourself if you want to.
What would happen if you'd try to login to an openid enabled slashdot? Well as a first step, you'd provide your openid url to slashdot (without password). Slashdot would then contact the server where the openid url comes from and ask it to confirm the identity. Assuming this is the first time you visit slashdot and that you are already logged into your openid account, you will be redirected to the the openid site and it will ask you if you want to give slashdot permission to authenticate you and also what personal data to expose to slashdot. Only if you give those permissions, slashdot will get an affirmative from the openid server. Next time you visit slashdot the process can be automated because you have already given slashdot the right permissions.
What benefits are in all this:
- slashdot never sees your password
- you only provide your password to your openid server (and of course you should change it on a regular basis as well).
- you have to grant slashdot the permission to authenticate you (and you can of course revoke this right as well).
- similarly you can grant the permission to use parts of your personal data (email, public pgp key, name, addresses, phonenumbers,
- these data items are centrally managed so you only have to change them once instead of updating your dozens of accounts.
- your identity + personal data is managed by a server you trust (or your own openid server if you don't trust anyone).
- should your identity be stolen, you have a central place to go to block the whole thing and change your password. At this point, you'll probably also be very interested in any server logs detailing what sites attempted to authenticate your stolen identity and ip numbers of computers who were claiming to be you.
Most of these features you don't get with the default slashdot login.
Then of course things can be layered on top of this. For example, a site asking for credentials could be required to provide proper certificates. And the openid server could warn users about potential phishing attempts by comparing the authenticating site automatically to a list of malicious sites; etc. To me that is a lot better than having a few dozen accounts on untrusted sites, all with a weak password (often the same too) and stupid endusers in charge of trust decisions they only half understand.
And of course there are similar advantages for sites verifying the identity with the openid server. They can check certificates of the authenticating server; compare the server address to a list of malicious identity servers and have a central point to complain in case of abuse.
The widespread adoption of a standardized version of this protocol could be a real step forward for the internet and make it a more secure place than todays internet.
The real problem is that very few teachers or professors have relevant experience when it comes to software engineering. Most of them have spent their entire professional life in the academic world where all they see is flexible deadlines and toy systems of at most 1 kloc. Most of them don't really understand the dynamics of medium to large software projects (100 kloc+).
Sadly software engineering education is still based on the model of master-apprentice. When people leave university, they basically know nothing relevant. They have no experience with the relevant tools and practically no exposure to the relevant library. If you are lucky they had a decent introduction to languages and algorithms. Probably they are really good at building parsers that nobody needs and optimizing data-structures that they shouldn't be reinventing in the first place. Beware of small consultancy startups with young software engineers. Most likely your project is their first real world experience.
There's all sorts of analogies you can make. Some are not so appropriate. But a key thing to understand is that the response to a perceived threat can actually be more of a problem than the threat itself. In the case of terror and 9/11, the response has been a major disruption of power balance in the middle east. It's hard to estimate exactly how many died, whose fault that was and whether these people had it coming or not. Fact remains that that number is many times the number of people killed on 9/11. Also some high ranked politicians and army people are actually voicing the opinion that terror threat actually got worse due to the invasion of Iraq. And of course even the number of US casualties in the war on terror is set to exceed the number of lives lost during 9/11 pretty soon.
:-).
Another interesting response to a threat is gun ownership (in response to perceived threat from crime). Many people die each year from accidents with guns bought for 'protection'. People end up accidentally shooting themselves, their relatives or innocent people who happen to be in the wrong place instead of the hypothetical burglar for which the gun was bought. There's actually people arming themselves to the teeth to 'protect' themselves from perceived threats without realizing that them being armed to the teeth is an accident waiting to happen. News reports of mentally unstable people (highschool kids in some cases) using legally purchased guns (plural!) are all to common in the US. It's hardly news anymore unless the killer manages to kill a few people. Also because there are so many guns, criminals are pretty much guaranteed to be armed. I'd probably want a gun if I were living in the US just because of that
Of course in computer security related matters, there's such interesting things as people losing unencrypted USB sticks with important files because their sysadmins made it impossible/difficult/inconvenient to transfer files using e.g. email or IM between their laptops. Lock down a system properly and your users will start being creative to find ways around your security measures. I've seen this so many time: oh can I borrow your usb stick to pass my confidential powerpoint slides to that guy over there? My company wastes vast amounts of money on laptop security. The measures have a severe impact on performance so everybody needs rediculously fast laptops just to do ordinary office stuff.
My thoughts exactly. I apply for jobs on invitation only and usually the job vacancy is tailored to my CV. The few times I got involved with recruiters have been bad experiences.
The job interview is there for me to decide whether I want the job. I always go into a job interview with that attitude (which btw is a great way to get yourself hired).
That may sound arrogant but that is the attitude you should expect from qualified people. They know they are good, others know they are good and if you do your homework you don't have to bother spending much time figuring out how good they are. By the time you are talking to them over a phone you should already be 95% sure you really want to hire the person in question. The problem then becomes convincing them to do that.
Job boards are there for people who for some reason have trouble getting invited to apply for jobs when they want another one (or worse, don't currently have one). They are a useful tool but by definition not the place to look for the best. It's a good place to find inexperienced junior SEs. Beware of people advertising their long career on a job board because they're there for reason!
So, some advice to companies looking to hire the best:
- Don't expect people to come to you, they won't. Also they won't read your job vacancy descriptions or kindly present themselves to your HR staff.
- Use your network to find potentially interesting candidates and if at all possible contact them through people they know and trust
- Assume that they have nice jobs and are not really looking for a job: i.e. do not approach them by phoning them during office hours
- Don't expect them to be enthusiastic when you approach them, you will need to sell your job to get the skills you need
- Be prepared and don't waste their time with non skill matching offers (i.e. don't waste people's time)
- Be specific about what you want from them and what you are offering in return.
- Be specific about the fact that you intent to hire them (assuming that you are by this point).
- Present your HR department as what it is: the people you have for dealing with boring formalities and not an obstacle for getting a job.
I'm posting this because I'm contacted frequently by stupid recruiters insisting on basically ignoring all of this advice. I usually turn them down before they even have a chance to offer me a job.
Upgrading the jvm does not cost that much. It's a free download and the upgrade is backwards compatible. On top of that 1.3 is now pretty much unsupported stuff and the 1.4.2 version performs a little better and has lots of nice improvements related to scalability. I'd recommend to go straight to the latest 1.5.0 runtime unless you have some very specific technical reason not to do so. And even then you should consider fixing it rather than not moving to 1.5. You can of course choose not to use the new language features for the moment (compile target="1.4").
I can understand that people are more reluctant to upgrade the application server but even so, j2ee 1.4 was mostly an incremental improvement over 1.3. Most of it was pretty good improvements and refinements.
It's not about things being broken and whether or not to fix things them but about making developers use old stuff for building new stuff. You're right if the systems are not being maintained anymore. But in reality people will be doing lots of maintenance on these systems. Statistics indicate that 60% of development cost is maintenance and I suspect J2EE systems are no different.
JEE 5 is a different story it's a major architectural change. Application server vendors are still lagging with implementations. I've used the incomplete jboss implementation that comes with jboss 4.0.4. It's nice and saved me a lot of time but the documentation still sucks and there's all sorts of little things that must be done just right to make JBoss do all the deployment magic. When it works it is great though but it's not production ready yet and the implementation is incomplete (even though it covers the more important bits and pieces of the spec now).
A lot is wrong with nepotism and corruption of which this kind of behavior is a symptom. Of course the EU is exactly not free from that either. Using political or economic pressures to influence a legal process in general is not a good thing. In both the EU and the US the legal framework that is meant to keep the political and legal word separate is eroding rapidly. Separation of church, state and law is a joke these days but it used to be a good idea.
The problem with lens technology is that there don't seem to be that much major breakthroughs anymore. Sensor technology on the other hand continues to improve rapidly. So, the main point of a next gen SLR will be the sensor, not the lens. You are probably right that increases in the number of pixels will not be the most relevant sensor improvements though. Being able to shoot with ISO 3200 or even more sensitive values without much noise will be features to look forward to. Right now pushing most cameras beyond 400-800 is already too much. Of course noise is less of an issue when you are shooting at 50 MPixel, you can afford to run elaborate noise canceling algorithms without too much loss in details with that kind of resolution.
Agreed, articles should go through some lifecycle where, as article quality increases, it should become harder to edit the article. Articles would start out editable for everyone and at some point, it would reach a stable state where approval of key individuals would be needed to publish further changes.
For example some articles like the one on Pythagoras are quite elaborate, extensive and by now probably more or less stable. There might still be valid reasons for making changes but probably reviewing such changes would be preferable to making them and then having others fix the damage later.
A nice model would be to have a built in delay (2 days) in the publishing + notification and the ability to object/ammend the change. So a user would add 'math suxors' to the pythagoras article and all the interested people in this aricle (previous authors?) would have 2 days to ammend/delete the change. After 2 days the change is published automatically unless somebody objected. In this case, the change would never be published.
You don't want this model for all articles, just for important articles (many hits or many refs to them) and stable articles. Both of these can be identified automatically. Ownership of articles would default to whomever did any changes to the article previously. Any disagreement with a change would prevent the change from being published until the conflict is resolved either by friendly discussion between reviewer and author or by normal wikipedia conflict resolution processes (whatever those may be right now).
Selling books in the education market is highly profitable business. Let me rephrase that: publisher profits in the education market are financed through government sponsorships (e.g. research grants); money intended for education (e.g. scholarships or parent contributions) and money earned by students in various jobs when they should be studying. If that's not good enough: students are more or less required to buy the books (provided you get teachers to endorse them). Vast amounts of money intended for education flow more or less directly to the publishers. Under many governments, that includes substantial portions of the tax money you pay.
Essentially the problem is the same as in the scientific article publishing business: authors see little or none of this revenue. Essentially, all the profit is for the publisher. If your name is Andrew Tanenbaum, well maybe you do get a nice salary from the hundreds of thousands of people buying your books. But otherwise, the fees do not come close to paying for the time invested in the books. These books tend to be printed in small editions of a few tens of thousands copies at best (production cost a few dollars each). The point is, authors mostly are not doing this for the money but for the honor (including having their book printed by a well known publisher).
The printing business made a lot of sense when distributing dead trees was the only means of distributing information, other than by re-enacting it in front of an audience (quite normal until the invention of book printing). Nowadays, books are all about convenience and having glossy covers on your shelf. The convenience consists mostly of having better contrast and the ability to 'scribble' in them. The shelf factor of many books is arguably more important than the actual content. Many books are never even read cover to cover!
The solution is simple: get the publishers out of the loop and distribute the books electronically under for example the creative commons license. For the price of a normal book you can easily finance printing the entire book on glossy paper with a really expensive inkjet printer in full color, should you wish to do so. Of course putting a bunch of laser print copies through a high volume copy machine is much faster and cheaper. And for some, reading stuff from a screen works just fine (you don't print slashdot 20 times per day, do you?).
There would of course need to be some infrastructure for editing, reviewing and ranking books (e.g. by references to it or endorsements by people/universities/schools). That should be a relatively simple problem to solve and I don't see the need for involvement of for profit publisher businesses in this. Additional value could be provided in the form of reader forums/blogs, regular updates to the content, reader provided exercises, references, etc.
That is incorrect. Some of these tools: e.g. Findbugs, pmd and lint4j are not about code style at all. Instead they look for real antipatterns and situations that usually indicate a bug. For example these tools will identify potential deadlock problems, obviously wrong uses of the synchronized keyword, draw your attention to null dereferences (npe at run time), streams that you forgot to close properly (i.e. in a finally block), etc. Some of these things can be quite hard to find in code and will slip through manual reviews. All of these tools come with hundreds of preconfigured rules and more are added with each release.
Some of the warnings can be categorized as not really relevant (and can be optionally disabled in the tool configuration) but most of the things these tools detect are things that you probably want to fix if you know about the problem. Sure these tools don't find all problems but they do find several types of important problems if they exist in your code 100% of the time. Personally, I'd like to know if some jerk forgot to close the database connection before I put the code on a production server. Findbugs gives me that information.
You mean like Matcher.replace(String s)?
/ regex/Matcher.html#replaceAll(java.lang.String)
http://java.sun.com/j2se/1.5.0/docs/api/java/util
I wouldn't call running across the field with a inflated device that is does not even resemble a spherical shape football. It seems neither feet (except for the running of course) nor balls are involved.
I don't know about your definition of interesting but most of the java stuff I work with on a daily basis works unmodified on the three big desktop platforms (and probably everything else that runs java 1.5) and does so for the ten or so years I've been developing Java. This stuff combined is probably several million lines of code. Also all of the stuff I write in Java is 100% crossplatform, barring the odd jdk bug that somehow fell through the 60000 or so unit tests they unleash on the jdk nowadays (just a disclaimer, can't recall ever encountering one). In my previous company we developed on windows, had staging servers running linux and deployed more or less blindly to our customer sites running windows 2000, 2003, various flavours of linux and even some sun machines. Worked every time. Portability was never an issue. Not even having to test for portability issues is a huge time and cost saver.
A good example of a portable J2ME app is opera mini which exists in only two variants the both of which work across pretty much all java capable phones except maybe for the really crappy ones, such as your Palm based one (blame Palm, not Sun). J2ME is a modular specification which unfortunately leads to the interesting situation that the more of the modules your app uses the less portable it becomes. Pretty much all of the modules are optional and with MIDP 1.0 many vendors added loads of vendor specific APIs as well. Many applications written for that mixed bag of standard and non standard extensions are not portable.
MIDP 2.0 mostly removes the need for vendor specific APIs (though many vendors still ship them). Upcoming MIDP 3.0 is even better apparently. of course many games need to make assumptions about device specifics (e.g. screen size, number of colours, keyboard layout) which unfortunately leads to many portability issues. These problems are hard to solve and currently J2ME seems the best solution the market has come up with. Most device specific binaries of J2ME apps merely include some minor modifications, optimizations and packaging. I agree that testing for all that is a major PITA for developers. If you have a better solution that works for non trivial applications across the thousands of different brands and types of mobile phones, get some venture capital and get rich!
I don't know, nobody seems to have bothered spending much time thinking about that. I think the past ten years have shown that design by committee is not the way to solve the problem in a satisfying way.
I'm not claiming there is an alternative just complaining about the lack of one. To me CSS seems awfully limiting. Some of the issues are being addressed in CSS3 so on paper that would be a nice improvement.
I'm not claiming web sites use flash a lot, just that it is the technology of choice for graphics designers. Reality forces them to downgrade to CSS+javascript+html in most real life situations but in terms of layout flexibility flash (or something similarly capable) is what they really want to use.
I used to care. Now I don't any more. I consider the whole batch of so called standards collectively known as the web pretty primitive and backwards. CSS is a horrible standard not suitable for defining moderately complicated layouts (or even certain trivial ones). It's not the best we've got it's just something put together in a hurry independently from the (surprise!) independently evolving implementations, ten years ago. Attempts to steer browser development through forward defining new revisions of this standards have largely failed. And browser developers after spending most of the last decade interpreting CSS 2 seem to slowly settle on an interpretation of a significant subset of this standard from 1999 (or was it even earlier)?. CSS3 can now safely considered to be as dead as a doornail with browser developers cherry picking the little bitts and pieces that are more or less finalized.
:-).
Acid2 is not about CSS compliance but about supporting the documented ambiguities in the standard correctly (many undocumented ones remain). These ambiguities include weird parser behaviour, browser quirksmode hacks for non standard pages etc. In short, it test the browsers ability to fuck up the rendering in a consistent way. Of course the biggest fuck up of them all (IE) fails the test so the test is pretty much worthless in practice. It even fails rendering incorrectly
Then there is HTML which evolved from a naive attempt to capture semantics of certain documents by Tim Berners Lee to a slightly worse specification (HTML 4.x) which isn't really good for anything it is designed to do (ranging from layout features to representing document semantics). The successors in the form of XHTML 1.x and 2.x drop the layout stuff (which sucked anyway) and tried to preserve most of the flawed semantics whilst adding new constructs and increasing complexity so much nobody really understands it. Market apathy has ensured that these xhtml standards never moved out of the lab. XHTML documents actually served up as application/xml (alledgedly the correct way to serve them up) are extremely rare although well formed versions of html 4.x are now commonly served up as xhtml 1.0 transitional (or even strict). Other than forcing the browser into a somewhat better defined way of rendering, this has little effect in terms of layout features compared to html 4.x.
Let me see what else have we got? There's crappy SVG which slowly seems to replace gifs for sclable icons on some systems and also leads a double life as a poor mans graphics exchange format. There's the hopelessly underpowered javascript language and the accompanying APIs (DOM *shudder*). There's MATHML which remains ever popular in very small niches. Most of the mentioned technologies lead a double life in the form of how they are supposed to work and how they actually work in practice. Pragmatic web developers just copy paste and adapt what works and ignore the rest. The smarter ones build up some knowledge of how things are supposed to work and where the bugs are for each implementation. All the graphics designers seem to have standardized on non standard flash. With standards nazis mainly telling them not to use flash, instead of providing an alternative, this is unlikely to change in the forseeable future.
But as said, I no longer care that much. Increasingly tools take care of generating the exotic hacks to make it all work. Handcoding something like gmail would probably drive programmers mad, which is why the nice google people embedded the difficult stuff in a nice library so they can focus on application functionality.
I've used lint4j, pmd, checstyle and indeed findbugs. These tools are very useful. The biggest problem is finding the time to fix the issues. It's tempting to skip the minor issues but then this is where you need to be strong.
I'd recommend that serious java developers integrate the above mentioned tools into their nightly builds and treat the identified issues as real bugs.
The reason I'm recommending subversion is because I strongly believe that development artifacts should be kept as close to the source code as possible (so when you branch or tag these artifacts are part of the operation instead of out of date binary blobs on some network drive). Since we are talking about functional specifications here that means storing them in a source repository and as far as I can see subversion is the best option. It supports efficient storage of binary files; easy integration with windows explorer; easy esposure through an intranet or even over internet via ssh or https; integration with webdav etc.
Do not use cvs. Period. There are no use cases left where cvs is better than subversion. Even the tooling now is comparable or better for subversion (e.g. tortoisesvn is much nicer than tortoisecvs) so the legacy tooling excuse for using cvs is no longer valid.
Or more general, virtualizing allows you to do dynamic optimizations in the interpretation of whatever virtualized API you are using. This how dynamically compiled Java can outperform statically compiled C for selected code fragments. This is also how HP showed a C vm outperforming compiled C on the same machine for selected programs. The vm could do optimizations at run time a compiler couldn't possibly do before run-time.
Native means performing according to whatever (naive) assumptions the compiler or programmer has to make about the run-time environment. Disk access is easy when your program is the only one talking to the drive. It's a different matter when there's hundreds of processes and thousands of threads from other programs are doing the same. That's why operating systems virtualize disk access and disks in turn also virtualize raw access to the disk platters (so your OS does not actually tell the disk when and how to position the heads). Disk performance would really suck without virtualization. So would writing any app that uses disks.
But still he is wrong. Understandable, he's never liked Java and there were a lot of public statements/announcements last week from SUN. One of them indeed was about the license change for distributing binaries. Another wasn't so much an announcement but a confirmation from the newly appointed CEO that SUN now intends to make java available as open source. This in response to questions from the audience on this topic. This has since been re-confirmed by him and several others inside SUN. Sure, that still not very specific with respect to what, when and how. But it is different from the simple 'no way' that Scott Mc Neally has been answering to this question for years.
If your businesslogic breaks when you change the site layout then embedding HTML in your business logic clearly was a bad idea. Doing so gets you up and running soon but you pay the price later when doing maintenance.
Putting some time and effort in separating logic and presentation is not a novelty. The MVC pattern dates from the seventies. The n-tier server architecture was invented shortly thereafter. These two are now well accepted architectures for separating logic and presentation.
As for performance. Code that mixes everything together tends to be naive in multiple ways, including performance, security, extensibility, etc. Optimizing performance generally requires using caching, pooling and other types of strategies. These are hard to retrofit in monolithic single tier systems. Again there's no absolute truth here: you just may be the genius that gets it right in one go.
So it all depends on the question are you the guy who's doing the maintenance and/or will you be there when the shit hits the fan when somebody else tries to do it for you. If so, you are probably better off doing a proper job. On the other hand, out of control IT projects are a great way to milk stupid customers. Many IT businesses have built their empire on that kind of incompetence and billions of dollars still change hands annually for software projects that are over time, over budget and ultimately disappointing.
This is the first comment in this thread to contribute something sensible. It is my personal opinion (based on observations in practice) that C based systems hit a hard ceiling in terms of managability around 3-5 million lines of code. Above that nobody can be found with a good enough mental map of the system to engineer it properly. This is not a hard limit, there's several ways to stretch it a bit. None of these ways involve technology: they are about process, discipline and engineering practice. With that in place (expensive) you can grow a few million lines of code more. Currently the largests systems around are around 100 million lines of code. These are complex beasts requiring the constant attention of thousands of software engineers. They take years to release and are only allowed to continue to exist because replacing them effectively is killing the company.
The C language provides so many vectors of severe stability and security issues that just isn't funny. Most of these technical issues have well working, tested and proven solutions in other programming languages. Shared memory space is only a problem if the compiler/run-time environment allows you to abuse it. Many programming environments exist that allow you to safely share data. Doing that from multiple threads is quite safe as well provided you understand what you are doing. Most problems in that area are related not to memory corruption but deadlock, race conditions, etc.
It's of course a non issue entirely in most scripting languages or virtual machine based languages. But statically compiled languages with similar performance characteristics to C exist as well. So I agree, C was an expensive mistake. Each crash/bsod/security leak/kernel panic/whatever, we pay the price.
So essentially users will be subsidizing the expensive, redundant and obsolete physical distribution chain involving (re)production of the discs, shipping, marketing, retailing and margins of all the people involved in all of the previous. Sounds like a great deal. Wake me up when prices drop to a more realistic level involving only content production cost + marketing + hosting (should be negligable using bittorrent).
Besides, I'm not at all interested in producer verticals. I want to buy on a horizontal market with multiple sources of content where competition happens based on price and quality of the content. I guess this is too much to expect from companies who are essentially entirely optional in a digital world and well aware of that.
In economic terms the problem of production and consumption is extremely simple. There's this notion of the value adding chain. Essentially that means that each step in the process is about making output more valuable then input (e.g. trees->wood->chair). Added value is something you can build a business on. The movie industries current idea of ading value is doing everything the old way, actually removing value (i.e. the physical media + consumer freedom) and then asking the same inflated price as before.
The market opportunity here is huge. With a distribution model that is essentially close to free, sales are pure profit. Maximizing the volume/revenue curve is the trick. Maintaining old prices, will ensure that volume stays limited to those few nuts who don't care about money, the dvd and just want to see the movie now. Not a big growth market. Then there's people like me who generally don't waste 20 dollars on a dvd unless they really want to see it (in my case, rarely). There's plenty of movies in the past few years that I have not seen and that I wouldn't mind seeing. I'd gladly pay a small fee for convenience here. In other words, I represent a market opportunity. If 20 people pay 2$ that is the same amount of revenue you get from 2 people buying the same movie for 20$. My guess is that there are a whole lot more people willing to spend 2$ on a movie than there are willing to spend 20$ on a movie (especially bad movies, something that hollywood specializes in). This in short is the iTunes businessmodel: people are paying 1$/song for stuff that is pretty hard to find in regular stores. That's pure profit (aside from the music industry tax).
Of the 50 million+ lines of code that make up windows, relatively few are in the kernel. Also most security bugs that are being found have no direct relation to kernel level code (e.g. many viruses do not even require admin rights to propagate and do their damage). Similarly, linux and unix security bugs are mostly found in user mode stuff like bind or openssh. Microkernels do little or nothing for such security related matters. As far as stability is concerned, both windows and linux tend to be quite stable these days except for the occasional crappy driver. Hardware stability is a much bigger issue (e.g. overheating components). The benefits of microkernels do exist but they solve only a small part of the stability and security issues experienced by users.
Rather than replacing current OS kernels by microkernels (which would take years if not decades), the soltution is to simply keep refactoring them. Both the linux kernel and the windows kernel are evolving and both include facilities for protecting memory; loading some drivers in user space; etc. I'm sure kernel developers have not yet run out of tricks to improve them further.