The same goes for independent software projects. By far the largest problem across linux distributions is integration testing. Basically quite many things only work properly if you handpick specific versions of components. Introduce a little variation (like package management systems do) and basically you are looking at a unique configuration of packages that has never been tested in that exact configuration before. Feature interaction and other package interdependencies can be really tricky to test against.
The current situation of major distributions hand picking their own versions of packages + introducing distribution specific patches to them only adds to this problem. And then of course independent software developers further add to the problem by only testing on specific configurations of specific distributions. And we all know what a typical developer's workstation looks like. Few projects have the resources to organize broader integration testing.
What Shuttleworth suggests is that merely synchronizing on package versions & release schedule would broaden the scope of integration testing and reduce the amount of mostly non differentiating and needless variation. Effectively it would unify the integration testing work already done across distributions & projects and raise the level of quality across the whole community.
It's hard to see how this can be a bad thing.
A second point that Shuttleworth makes is that independent projects have their own roadmaps for stable releases. Distributions often have to deal with the fact that a nearly ready version of some component is vastly better than the year old stable version. That creates a dilemma: ship the old stable version or let users benefit from loads of useful fixes (that ultimately make the distribution more attractive). Firefox 3 beta 5 in Ubuntu was a good example. Probably a good decision but obviously the combination of OS and browser which at the time were both moving targets cannot have possibly been tested as well as would be desirable for a browser in a major desktop OS.
Wouldn't it be great if Mozilla had known a year in advance that if they'd pushed out Firefox 3 early April 2008, it would have made it into Fedora 9, Ubuntu 8.04, Slackware and Open Solaris release that each ship the exact same version of critical components that Firefox depends on.
Yes agreed. What is needed is a new architecture that will allow non destructive editing (photoshop doesn't do this very well either), support for all color models at all relevant bit depths, the notion of computational photography, semi-real time editing (e.g. toggling layers is painfully slow in the Gimp 2.4.5 win32) and a UI that supports modern notions of photography workflow such as embedded in products like adobe lightroom or new kids on the block such as a very interesting product called lightzone which seems to have a few nice concepts or features. Also very intriguing is a product called naked light which essentially decouples the (non destructive) editing from bit depth, resolution and color space.
What I'm missing in the Gimp and similar OSS projects is basically a vision for the future. There seems to be no open source projects that are even trying to catch up with before mentioned products. Things like Krita and paint.net are all quite interesting but basically they are stuck trying to imitate adobe photoshop. Their main point seems to be that their UIs don't suck as much as the Gimp. Adobe itself has long moved on to adobe lightroom because they are feeling the heat from commercial competitors rather than OSS.
I'm not sure the Gimp can be evolved to do all this.
So my point is that Ubuntu has officially announced end of life for 6.10 to be April 25th and that they will stop patching security only 18 months later. 18 + 18 is 36 (i.e. 3 years) which is exactly the period after which my work laptop is due to be replaced. 18 months is not long term and neither is 36.
So I'm not a fucking retard, thank you very much. Next time you call someone a retard, check your facts. Also you might want to reflect on what that actually makes you (you might want to use a mirror to check your behind).
Your impression of things being alright does not constitute a fact. It's merely an impression. Real world security is very much like computer security: how you feel about security has little or no relation to how secure you are. Hellman knows this.
The US has used this knowledge to great advantage using propaganda at various times in its history. The anti communist-propaganda in the fifties was a great example. So was the weapons of mass destruction campaign just a few years ago. In both cases the aim was to spread panic in order to do what was perceived as necessary to protect the oil business. Given the oil prices today, this was probably misguided. As was the rest of that war.
The US government also uses this tool in the opposite way. Major incidents are routinely played down or not reported at all. Or when they are reported the facts are misrepresented. This creates a false sense of security. For example, US marines getting blown up in Iraq on a daily basis was kind of hard to keep out of the news but you can always try to give a positive swing to it and try to keep the pictures of the flag covered coffins out of the news. Like everything George Bush does, he botched that as well since the pictures got out.
So now the issue is that both the US and Russia have been providing nuclear technology to various unstable regions such as Israel, Taiwan (oops sorry for sending those detonators, yeah right), Pakistan, India, Iran, North Korea and maybe a few others. Luckily, Reagan only sent Stinger missiles to his buddy Bin Laden in Afghanistan in the eighties.
So, I find the theory that the probability of one of the powers that be in such regions hitting the big red button is much worse than once in a million years to be quite credible at face value. The big question is just how bad things are. I'm hoping the rest of the world is not so trigger happy when it happens but the probability for that might be such that the event is quite likely to happen. Another possibility is of course that at some point somebody repeats the Manhattan project by putting all the little pieces of the puzzle together or by stealing & acquiring the necessary information. This is roughly how Pakistan became a nuclear power.
So I don't care so much about how you feel about it. Probably for the economy it is actually best if you and most other people are blissfully ignorant. But on the other hand a little recession is a small price to pay for some good quality protection. All I know is that some smart guy that seems to have done a lot of homework seems to be pointing out that facts are pointing towards likely escalation to full nuclear war. And as a software engineer, I do know Murphy's Law.
Risk assessment for total destruction of this planet and all life on it should probably be biased a little towards being overly pessimistic on things happening side rather than optimistic on the things not happening side. After all, if you are wrong nothing happens and if you are right, you had some time to do something about it. Consequently, claiming everything is fine is rather fatalistic.
I think we are well into apples and oranges territory here.
Lets say your mileage may vary. It all depends on what packages you install, which on a typical Debian server is conveniently not that many. Regardless, I wouldn't recommend dist upgrades on a production server. There's just too much that can go wrong that will cause you downtime. Of course, once broken, a Debian install is still pretty fixable. Come to think of it, I've never experienced a clean install with Debian for which I did not have to fix major things like e.g. x, networking, sound etc. Or indeed all of these like the last release of Ubuntu I tried on my PC. If your (reasonable) expectation is you have to do that again after a dist-upgrade then yes, Ubuntu is great.
Upgrading win2k all the way to Vista is indeed a challenge (and bloody unlikely given the hardware requirements). I don't think windows OS upgrades have ever worked properly though apparently some were happy with the results. I think even Microsoft recommends against it. Last time I had the choice I went the clean installation route. That was in 2000.
I don't think Ubuntu upgrades get quite the amount of testing that windows service packs do. Generally, you might count yourself lucky if it just works. Most people I know that use Ubuntu prefer the good old format + clean install approach. I know I have certainly dist upgraded many Debian and ubuntu installs to the point where that indeed seemed the easy way out. Windows XP on the other hand seems reasonably well behaved with service pack installs. At least I don't recall ever running into major problems with service packs of either windows 2000 or XP. The reason is that these were designed and extensively tested to be installed on existing installs.
So my comparison is entirely fair. But to be completely fair, my 2.5 year old laptop was already running sp2 when I received it. You see, it was released in 2004. Of course the upcoming SP3 is long overdue but I'm not anticipating major problems there.
Ironically, the previous and soon to be abandoned LTS was released just a few short months before Vista was released. I've been running XP through basically the entire lifespan of Ubuntu, most of which became abandonware shortly after release.
It strikes me as odd that MS is getting bad press over discontinuing support for something when all of its competitors (including Apple) maintain vastly shorter update cycles and basically force their customers into frequent update cycles. Ubuntu did the 6.04, 6.10 (LTS), 7.04, 7.10 and soon 8.04 releases in the 2.5 year lifespan of my IBM/lenovo thinkpad. It's not scheduled to be replaced until after 8.10. So this series includes two LTS releases, one of which will be obsoleted before my new laptop arrives. So theoretically (since there was no such thing when I got my laptop), the last LTS release it could have been prepackaged with was 5.04 (aka 1.0?) and I would have had to go through two major OS upgrades in the normal lifespan of my laptop just to get a decent level of security patches/important fixes and support from Ubuntu.
I'm not saying XP is great (it isn't) but I have used it on four different work desktops since 2000 without too much hassle and it is basically still getting the job done.
Gnu's Java compiler (not a full vm as far as I know) doesn't pass Sun's test suits as far as I know. There are quite a few VM implementations around and the ones that Sun actually allows to use their trademark all pass extensive sets of testsuits. Things like gnu classpath and apache harmony are very compatible as well (although not yet 100% complete implementations) of the API as well. That still leaves some room for incompatibilities but these tend to be very minor. There's no such thing for C++. There's just the specification which despite all the hard work has many ambiguities and lacks a widely used reference implementation. This leaves the door wide open to implementation differences. Things have been improving of course but it isn't even close to how different Java vms are compatible.
In any case, idealism aside, there's no good technical reason I'm aware of to use the Gnu JVM. It's slower, less scalable, has more bugs and implements less of the standard. Even the license ceased to be an issue some time ago. You are better of running e.g. the Sun compiler or one of the commercially available VMs such as JRockit or the IBM JVM. Red Hat maintains a nice branch of the official Java code that is 100% free of the few remaining closed source dependencies (beer & speech).
Yep, smalltalk definitely deserves credit here. It still has some nice characteristics over Java.
Arguably the main contribution of Java has been bringing all the smalltalk goodies to mainstream (finally). Some compromises were made along the way but the overall result is still pretty nice.
That's why you shouldn't have set your classpath as an environment variable but using the commandline; via declared dependencies in the jar file or using something like OSGI.
As far as I understand, python 2.2 and 2.5 are quite far apart and 3.0 will break language and platform compatibility. It kind of matters which python you have. Good luck with the version from 1995. I happen to run into this a lot because pys60 is based on 2.2 which means that most third party stuff doesn't work there. Thanks to dynamic typing you find that out when things break or don't parse.
And perl, please... Apples and oranges, nuff said.
I actually know what I am doing when messing with Java and it also helps that I actually understand (and even appreciate) how the classloader works (another quite brilliant design decision from SUN), so no this has never been an issue for me. I'm quite handy with tomcat and yes, I've worked on real and I might say pretty obscure systems.
Basically all it takes is having a clue and setting up your build and deploy environment properly. Clueless idiots manually copying libraries to what they think is the right place is indeed a nuisance. Any idiot can break any system. As for debugging, I actually kind of like attaching to a JVM and inspecting what is going on in full detail (remotely). I don't know of many other systems that allow me to do that.
What Java version hell?! It's perfectly backwards compatible (binary and api, minor API bug fixes and deprecations aside). I've been developing on it since 1995 so I have some idea what I'm talking about. I think Java is probably one of the cleanest evolving platforms around (given the massive changes to it since 1995). Compare this to linux where binary compatibility is routinely broken for minor compiler version increments or libc updates. Compare this to C++ which didn't even have a widely endorsed spec until this millennium and continues to have many incompatible compilers (never mind the APIs, I'm just talking about the language semantics here). Arguably, C++ is still a mess.
I think you are also wrong about virtualization. The whole point of virtualization is to abstract away OS specifics to the point where it literally is nothing more than a commodity needed to run the vm. Who cares if it is mac, windows or linux running your php/Java/ruby server? If you are doing LAMP development, virtualization is what allows you to scale your new hot web application using Amazon provided service on demand stuff. Stuff like JRuby shows that virtualization can actually be fast and scalable too (it's basically kicking regular ruby's ass). Jython is basically going the same way.
Microsoft certainly had the right ideas with.Net. Their execution is less than perfect, however. Basically an old Java 1.4 hotspot VM still kicks the CLR's ass easily. In terms of scalability and performance there is really no contest between the two. Nevermind, later versions. However, the CLR design is interesting in some respects and some of the stuff MS has done on top of it is quite innovative. But the truth is that the Java platform is still a fine piece of engineering. Many controversial design decisions taken by Sun in the early nineties around this platform are now slowly being picked up elsewhere too. Basically modern compiler architectures like llvm bring stuff that Sun has been doing for years with Java to mainstream. The whole notion of garbage collection has basically displaced the notion of manually allocating memory (except in the most conservative environments). People do web development in environments that are much slower, crappier and less secure than Java (cough php cough) because development speed is so nice to have. In short pretty much everything Java is doing on the server side has been validated through others imitating with varying degrees of success.
That's not really a problem, bandwidth and storage are both dirt cheap (except if you are a big ISP). 95% of it is spam anyway (technically this is an etiquette problem as well).
The problem with mail etiquette is that it requires continuous education of users which given the lack of clear benefit for them is not something you can waste lots of time on in a corporate setting (close to irrelevant from business perspective) which is why this has been a total non issue since the day people invented this mail etiquette. It sort of worked while the internet was smelly, idealistic hippies using pine/elm/or worse but after normal people started using email it quickly broke down for the obvious reason that it was basically unenforcable. This was around 1994/1995 probably. Ever since old fashioned types have been bitching about this.
As other people have pointed out, gmail does a nice job of fixing the damage to your inbox. Technology is always a better solution than mass behavior modification.
I did a pretty traditional CS study. Most of the math there was nice but I never needed much of it. I guess most I got out of it in the end is generic analytical skills. These are useful to have of course. These days there is a broad range of topics in computer science and not all of it is related to math. Probably relevance of math for the type of jobs most CS students end up doing is fairly limited.
It's funny you are claiming software engineering and computer science are two fields. I guess software engineering has been evolving into a discipline of its own. But to the best of my knowledge software engineering is still taught in the CS department of most universities as part of the normal CS curriculum.
We can argue at length about Ada and its merits and how dead/alive it is or was. Pretty pointless in my opinion and I think the job market at this point is slightly biased in my point of view. In my view the DOD type projects are niche of its own and of course the use of Ada has always been limited to such very specific niches and domains to begin with. I've never encountered any Ada software in the real world. Maybe I'm just too young (33):-).
And how many million programmers do you share your niche with? If you go look you'll probably find people hacking just about any language that was ever invented. That doesn't mean fortran, cobol and many of the other lovely stuff popular decades ago (including indeed Ada) isn't dead.
In general supply and demand tend to meet each other. If you find that people aren't meeting the demand (e.g. compilers for 8 bit microcontrollers) for your niche that is maybe because demand is not so strong anymore.
1. Mathematics requirements in CS programs are shrinking.
The reason is because Computer Science has developed into a discipline that is no longer pure mathematics. There's only so many courses you can squeeze into four years.
2. The development of programming skills in several languages is giving way to cookbook approaches using large libraries and special-purpose packages.
Guess what, that's what building real software is like today. We don't need people that can write quicksort in obscure unused languages but people that can grasp systems of millions of lines of code. Ada doesn't prepare you for that because it is a toy language that never really was adopted outside of the academic world. It has no good, widely used frameworks & libraries like you find in the real world. People don't use it for a whole range of software systems that you find in the real world and to prepare you for this real world there are simply much better languages around these days.
3. The resulting set of skills is insufficient for today's software industry (in particular for safety and security purposes) and, unfortunately, matches well what the outsourcing industry can offer. We are training easily replaceable professionals.
I agree that skills are important. A good prof can teach those using pretty much any turing complete language if it needs to be done. Java isn't half bad for teaching a whole lot of important CS concepts and theory. And unlike Ada, people actually use it. As for C and C++ they are useful languages to learn of course. Many colleges still do.
But of course two ex profs working for adacore are hardly objective. Ada is as dead as latin. It has some nice features but nothing you won't find somewhere else. Keeping professional skills up to date is as important for professors as it is for students. Having done a Ph. D. in software engineering & architecture and having practiced my skills in several companies, my view is that one of the largest problems in computer science education is teachers who have never worked on real, industrial sized software systems and continue to send students into industry with a lot of misguided & naive ideas about how to build software. Most SE teachers out there simply have no clue what they are talking about. Software engineering is a skill learned in practice because the teachers in university mostly lack the skills required to properly prepare students. That's the sad reality.
So basically you are telling all those companies out there considering to switch to linux that in 6 months there is going to be noone around to support whatever they are installing now?. Pretty tough message either they install stuff that is pretty much untested and might become usable over the next year or they install stuff that is pretty well tested but that nobody wants to support anymore. Sounds like Microsoft stopping support for XP when they were still beta testing Vista (which some people might argue is still ongoing). Building good quality software is about more than tossing the next version over the fence: you need to have a credible plan for the most loyal users of the old version.
The KDE people are not willing to support 3.5 for five more years (the duration of LTS support contracts of Ubuntu). That's understandable. Even Microsoft plans to end commercial support for XP before then. But at the same time, 4.0 is in no shape to make it into a LTS supported release either.
The problem here is fundamentally that release schedules of various OSS projects are poorly aligned and that that occasionally leads to regrettable delays in getting software in the hands of people. Only a small portion of users ends up using the latest and greatest. For something like a major desktop platform release, the transition period is measured in years. KDE 4.0 will take quite some time to get adopted. Now is not a good time to stuff it into a LTS distribution.
It's not only type checking but tool maturity is what really bugs me. The development tooling for dynamically typed languages is complete crap and quite literally many years behind to what Java developers are used to. I had to do some python django coding recently and sure it is a nice framework for simple stupid stuff that wasn't so hard anyway. But damn it, I'm fixing stuff all the time that normally eclipse points out when I'm typing it in Java. Stuff like "this identifier is nowhere to be seen on the imports, shall I fix it for you?". It's trivial to fix of course but it just sucks finding it out at runtime, having to fix it manually and never knowing for sure if you've covered all the code paths. When doing java development in eclipse, I just ctrl+1 + enter, or ctrl+shift+o (organize imports), or ctrl+s (I have organize imports automatically run on save). I don't actually have to think about importing stuff. That's just one example. Of course I'm using the python plugin for eclipse but it seems to be quite buggy and it only half works.
Amazingly, many python programmers settle for seventies style tools (editor + console) and completely rely on the interpreter & reality to point out what they did wrong this time. That is just stupid.
I've been going through a edit, restart django, hit F5, analyze the stupid shit it throws at me this time cycle non stop for weeks now. I haven't had to do that in years, and it isn't fun. It makes me waste shitloads of time typing stuff I usually ctrl+space and running into whole categories of bugs and issues that I'm normally stopped from introducing. It doesn't help of course that all exceptions fall through forcing you to first experience problems before you fix them. And of course most exceptions take some very specific circumstances which is why the web is full of web pages that were clearly the result of some uncaught exception.
Additionally, I miss all the goodies that come with (or can be plugged into) a good Java IDE like static code analysis (metrics, common bug patterns, bad practices), good refactoring support (PDT has some but it is buggy), code templates (like generate a nice for loop on this array or put a nice try catch around this line with all the right exceptions caught) quick fixes, guaranteed executability if the IDE doesn't complain (not the same as correctnees of course). And that's just the stuff I actually use regularly. There's also things like debuggers that you can attach to a server, remotely; monitoring and management tooling built into most decent Java application servers, profiling tools that tell you where the bottlenecks are in your running software, etc.
For me the only real value of languages like python and ruby are the expressiveness provided by functional programming like constructs you don't have in Java (currently). These are kind of nice to have. Programming the same stuff in Java takes a few more lines and extra lines of code are more bugs (statistically bugs / LOC is more or less constant so more LOC = more bugs). Java programs are measurably larger in terms of LOC compared to python or ruby, just like they are measurably much smaller when compared to C/C++. This difference in size means you get better productivity and less bugs. But the tooling just needs to catch up with this century. If dynamic typing is the reason that can't be done: fix the bug and remove it already.
Smart tools mean more time for the real work. If I need to do real work, I use something like Java or something with similarly capable tooling (technically that is more and more a hypothetical language, you might argue C# has some of the goodies here).
BTW. I'm aware of progress being made here. I played around with ruby in netbeans 6.0 a few days ago and it was looking quite good. It even automatically upgraded railse to 2.0.1. Nice. All on top of JRuby of course:-).
QR codes are not just about advertising. They're just a quick way to get small bits of information into your phone. There's lots of use cases aside from advertising. For example, you could print one on your businesscard or display one on a website. A QR code on a business card could contain a url to a vcard (or the vcard itself). So basically to add someone to your contacts, just point the phone to the business card and snap. Same with any url.
The killer use case is not having to type in stuff on your phone. Urls on phones suck: they don't fit on the screen and typically take 30+ keypresses to type in. So currently that means if you see a url that you might want to check out, you have to write it down or remember it and then much later (if you don't forget) you might check it out on your PC. In most cases that means you are not going to bother at all.
Of course, printing QR codes is only one usecase. You can also just display them on a screen. I use a firefox extension (mobile barcoder, http://www.sample.org.uk/blog/?action=post&post=mobile_barcoder) that converts the url in the addressbar into a QR code. Whenever I want to do something with a URL in my phone, I just hover my mouse over the thing, snap and done. This works great.
You're wrong. The basic problem of browser developers vs. armchair standardization experts is that unless browsers render most pages as intended, users will use something else. That is kind of a hard reality that you can't ignore if you are serving up Firefox, Safari or Opera to millions of users. If they'd get strict about the current standards, the web would break down in their browsers. One of the HTML 5 guys (Ian Hixie) at Google has analyzed millions of pages and his conclusions are: 95%+ of the web is broken in some way; mime-types are an unreliable way to detect content-type and most document DTD headers are in fact incorrect or misleading in most cases and redundant at best (because version is also specified in html tag in correct documents). Browsers have to deal with this reality. Besides, DTDs are an obsolete mechanism that has long been replaced by more powerful schema languages.
The HTML 5 spec is being written and pushed by browser vendors. Html 5 is being supported as it is being written. It's being designed with sound engineering principles in mind: don't needlessly break existing content; provide forward and backward compatible ways to add new meaningful features (which after a decade of complete stagnation is very welcome) and precisely define semantics of the language as well as its processing and handling of incorrect html (in a way that consolidates browser behavior). This is a very pragmatic approach to improving the web and the effects are visible today in that an increasingly wider set of features works across latest versions of all major browsers. A sound principle of any kind of data processing application is to be strict about you send and very flexible about what you receive.
Most of the proposed changes in HTML 5 are very pragmatic and easy to support by browser vendors. They drop DTD support because it has proven to be completely useless and unreliable in the current web. Namespaces require something that no browser implements in the HTML rendering pipeline (full XML support). Compound documents are possible without them. Besides, HTML has links for a reason. Why embed stuff if you can link it? Html 5 is designed such that HTML 4 users can migrate to it easily rather than having to completely start from scratch. In other words it doesn't break any of the thousands of tools and content management systems out there and instead works with them. HTML 5 is also designed to degrade gracefully in browsers that don't support it so that HTML 5 content providers don't have to worry about supporting old browsers.
XHTML is not a successor but a competitor to HTML. It requires a completely different browser architecture to handle properly. Most browsers that currently handle XHTML at all have to fall back to slower rendering engines with features like incremental rendering not implemented. Basically serving up XHTML as application/xml mime type is a bad idea for this reason alone. HTML 5 is not about every browser vendor starting from scratch but about them adding useful features to a 10 year old architecture. To the armchair XHTML evangelists this might seem to be a non argument. But then armchair XHTML evangelists can't be bothered to write a proper XHTML browser that everybody wants to use either.
YANAL but I had some IPR trainings where this kind of stuff was discussed at length.
Technically copyright applies automatically in most countries. The act of creating something means copyright is granted to you on the form (i.e. not the idea like in patents). Licenses (free or otherwise) are designed to grant you rights and/or restrict rights. This can take the form of "do whatever you want" (e.g. MIT license); contracts specifying in legal terms your rights and obligations (e.g. most commercial licenses, apache and epl) or copyleft licenses (e.g. GPL) that try to negate copyright and turn its restrictions into freedoms.
In other word without a license normal copyright applies and you are legally required to get explicit permission to do things with the code (like using, copying, redistributing, etc.). Of course you could argue that such permissions are implied by posting it to a public forum. Legally it is a bit a grey area and you might wonder whether the person posting the code is actually the copyright owner. The nice thing to do is just try to contact the person who published it. More than likely they'll be happy to help you out.
Of course there is the practical side to things and it is pretty unlikely you'll ever be sued for this. Reusing small bits of code that people post on the net is pretty common. That's how the whole GNU thing started. The legal framework of the GPL and other licenses emerged as this practice became more widely spread because various people & companies were starting to apply copyright law and restricting people's rights.
That's true in theory but in practice most C programmers have no clue about underlying hardware architecture so 100% control amounts to random and arbitrary optimizations (and sometimes dangerous/counter productive) in most cases. The VM that the hardware presents to the compiler is not that different from the bytecode VM Java presents only more complicated, full of legacy features that no longer make sense and implemented in hardware. Underneath the processor translates to its real processor architecture which is probably quite alien to what most programmers are used to.
Also C programmers can only optimize for so many platforms and the optimizations can be different and even conflicting for each one. With a optimizing JIT, you can automatically optimize at run-time and apply any appropriate platform specific optimizations it knows about as well as optimizations that take into account measured performance of the running application. Doing the same in C requires dozens of different binaries and source code level optimizations just to target recent variations of X86 processors. Linux distributions have only recently started defaulting to 586 or 686 code instead of 386 code.
That's why a new compiler architecture is under construction (LLVM) that can do similar run-time optimizations to what Java is doing today. It makes sense to do optimization at run-time, also for C software.
By design that is not possible. But you might run into an exploitable bug in the native code of the vm that allows people to bypass security measures. This is true for any native software on your system. These exploits are getting pretty rare in Java though and I can't actually recall any major Java related exploits in recent years. There have been security related patches of course from Sun and most of them for good reasons. Additionally, you could install a Java application with bugs that are exploitable (but you can write buggy software in any language of course).
But by design Java is more secure than a typical native application because it protects against most memory and pointer related bugs that are used for installing worms or viruses. Additionally there is a security mechanism that provides fine grained access over which parts of the APIs are accessible to developers. This mechanism is used in applets to prevent developers from doing things you wouldn't want them to do. I'm not aware of any major applet related exploits in recent years and aside from flash and pdf, Java is still one of the most common browser plugins.
Browsers are of course a common vector for all sorts of malware but Java is rarely the cause of the misery. More common is buggy javascript parsing (by the browser); poor handling of URLs and other bugs in the decade old rendering architectures of IE and Mozilla which both are full of obscure C and C++ code that nobody really understands in full. Mozilla has spent the last two years re-architecting their browser backend to refactor memory usage and get rid of countless memory leaks, bugs and other things that didn't entirely work as designed. They did some great work there. So if you are comfortable running that on your system it would be downright irrational to have any concerns running Java. Your system is only as secure as the weakest component on it. If you are running windows 9x, it doesn't really matter what you install on it from security point of view.
BTW. Inherent security of the Java platform is also a good reason to run many serverside scripting languages inside a Java VM. For example Php has a history of many exploits, many of which simply don't work inside caucho php port to java (http://www.caucho.com/). Similar advantages apply to using jruby instead of ruby. And of course you might be able to gain a little scalability and manageability.
Tried it, don't like it
on
Miro Turns 1.0
·
· Score: 4, Informative
The concept of Miro is appealing: having videos you are interested in download automatically and have them available for watching. Miro tries to do this. The problem is that it is a mediocre feed reader; a mediocre bittorrent client and a mediocre media player. Consequently it is not replacing any of these on my machine.
Unfortunately there is lots of rough edges that are known but not addressed in this 1.0 release. For example, Miro hogs bandwidth on my PC. Because it is hogging bandwidth, forget about doing things like browsing the web or accessing the miro guide when it is running. In other words, it renders the connection unusable. Most p2p clients have options to configure and constrain upload and download bandwidth capacity. I've never used a p2p application that worked without providing reasonable settings for such options (like a few kilobytes below the max capacity for upload and download to prevent being throttled by the ISP router). Miro lacks these options. I have a ordinary cable internet connection similar to what most home users would have, nothing special. So likely this affects most users.
Additionally, I don't like the built in media player. VLC is nice if you can configure it properly but that is not possible with the options screen in Miro. There's no option to launch video in an external media player.
Finally, many options default to rather annoying settings. For example subscribing to a feed results in Miro automatically downloading all new items in that feed. That just sucks unless you subscribe to only a handful of feeds. Basically it results in the automatic downloading of stuff you'll never watch and the delaying of downloads that you might actually want to watch. Additionally no way to prioritize here of course.
Altogether this feels like a premature release. They should have spent a bit more time polishing and fixing obvious issues.
Slashdot Mirror
The same goes for independent software projects. By far the largest problem across linux distributions is integration testing. Basically quite many things only work properly if you handpick specific versions of components. Introduce a little variation (like package management systems do) and basically you are looking at a unique configuration of packages that has never been tested in that exact configuration before. Feature interaction and other package interdependencies can be really tricky to test against.
The current situation of major distributions hand picking their own versions of packages + introducing distribution specific patches to them only adds to this problem. And then of course independent software developers further add to the problem by only testing on specific configurations of specific distributions. And we all know what a typical developer's workstation looks like. Few projects have the resources to organize broader integration testing.
What Shuttleworth suggests is that merely synchronizing on package versions & release schedule would broaden the scope of integration testing and reduce the amount of mostly non differentiating and needless variation. Effectively it would unify the integration testing work already done across distributions & projects and raise the level of quality across the whole community.
It's hard to see how this can be a bad thing.
A second point that Shuttleworth makes is that independent projects have their own roadmaps for stable releases. Distributions often have to deal with the fact that a nearly ready version of some component is vastly better than the year old stable version. That creates a dilemma: ship the old stable version or let users benefit from loads of useful fixes (that ultimately make the distribution more attractive). Firefox 3 beta 5 in Ubuntu was a good example. Probably a good decision but obviously the combination of OS and browser which at the time were both moving targets cannot have possibly been tested as well as would be desirable for a browser in a major desktop OS.
Wouldn't it be great if Mozilla had known a year in advance that if they'd pushed out Firefox 3 early April 2008, it would have made it into Fedora 9, Ubuntu 8.04, Slackware and Open Solaris release that each ship the exact same version of critical components that Firefox depends on.
Related to this, here is a nice overview of the current state of various Ruby implementations (including a brief discussion of the javascript one) by Charles Nutter one of the lead developers of JRuby: http://headius.blogspot.com/2008/04/promise-and-peril-for-alternative-ruby.html
Yes agreed. What is needed is a new architecture that will allow non destructive editing (photoshop doesn't do this very well either), support for all color models at all relevant bit depths, the notion of computational photography, semi-real time editing (e.g. toggling layers is painfully slow in the Gimp 2.4.5 win32) and a UI that supports modern notions of photography workflow such as embedded in products like adobe lightroom or new kids on the block such as a very interesting product called lightzone which seems to have a few nice concepts or features. Also very intriguing is a product called naked light which essentially decouples the (non destructive) editing from bit depth, resolution and color space.
What I'm missing in the Gimp and similar OSS projects is basically a vision for the future. There seems to be no open source projects that are even trying to catch up with before mentioned products. Things like Krita and paint.net are all quite interesting but basically they are stuck trying to imitate adobe photoshop. Their main point seems to be that their UIs don't suck as much as the Gimp. Adobe itself has long moved on to adobe lightroom because they are feeling the heat from commercial competitors rather than OSS.
I'm not sure the Gimp can be evolved to do all this.
http://www.ubuntu.com/news/ubuntu610end-of-life
So my point is that Ubuntu has officially announced end of life for 6.10 to be April 25th and that they will stop patching security only 18 months later. 18 + 18 is 36 (i.e. 3 years) which is exactly the period after which my work laptop is due to be replaced. 18 months is not long term and neither is 36.
So I'm not a fucking retard, thank you very much. Next time you call someone a retard, check your facts. Also you might want to reflect on what that actually makes you (you might want to use a mirror to check your behind).
Your impression of things being alright does not constitute a fact. It's merely an impression. Real world security is very much like computer security: how you feel about security has little or no relation to how secure you are. Hellman knows this.
The US has used this knowledge to great advantage using propaganda at various times in its history. The anti communist-propaganda in the fifties was a great example. So was the weapons of mass destruction campaign just a few years ago. In both cases the aim was to spread panic in order to do what was perceived as necessary to protect the oil business. Given the oil prices today, this was probably misguided. As was the rest of that war.
The US government also uses this tool in the opposite way. Major incidents are routinely played down or not reported at all. Or when they are reported the facts are misrepresented. This creates a false sense of security. For example, US marines getting blown up in Iraq on a daily basis was kind of hard to keep out of the news but you can always try to give a positive swing to it and try to keep the pictures of the flag covered coffins out of the news. Like everything George Bush does, he botched that as well since the pictures got out.
So now the issue is that both the US and Russia have been providing nuclear technology to various unstable regions such as Israel, Taiwan (oops sorry for sending those detonators, yeah right), Pakistan, India, Iran, North Korea and maybe a few others. Luckily, Reagan only sent Stinger missiles to his buddy Bin Laden in Afghanistan in the eighties.
So, I find the theory that the probability of one of the powers that be in such regions hitting the big red button is much worse than once in a million years to be quite credible at face value. The big question is just how bad things are. I'm hoping the rest of the world is not so trigger happy when it happens but the probability for that might be such that the event is quite likely to happen. Another possibility is of course that at some point somebody repeats the Manhattan project by putting all the little pieces of the puzzle together or by stealing & acquiring the necessary information. This is roughly how Pakistan became a nuclear power.
So I don't care so much about how you feel about it. Probably for the economy it is actually best if you and most other people are blissfully ignorant. But on the other hand a little recession is a small price to pay for some good quality protection. All I know is that some smart guy that seems to have done a lot of homework seems to be pointing out that facts are pointing towards likely escalation to full nuclear war. And as a software engineer, I do know Murphy's Law.
Risk assessment for total destruction of this planet and all life on it should probably be biased a little towards being overly pessimistic on things happening side rather than optimistic on the things not happening side. After all, if you are wrong nothing happens and if you are right, you had some time to do something about it. Consequently, claiming everything is fine is rather fatalistic.
I think we are well into apples and oranges territory here.
Lets say your mileage may vary. It all depends on what packages you install, which on a typical Debian server is conveniently not that many. Regardless, I wouldn't recommend dist upgrades on a production server. There's just too much that can go wrong that will cause you downtime. Of course, once broken, a Debian install is still pretty fixable. Come to think of it, I've never experienced a clean install with Debian for which I did not have to fix major things like e.g. x, networking, sound etc. Or indeed all of these like the last release of Ubuntu I tried on my PC. If your (reasonable) expectation is you have to do that again after a dist-upgrade then yes, Ubuntu is great.
Upgrading win2k all the way to Vista is indeed a challenge (and bloody unlikely given the hardware requirements). I don't think windows OS upgrades have ever worked properly though apparently some were happy with the results. I think even Microsoft recommends against it. Last time I had the choice I went the clean installation route. That was in 2000.
I don't think Ubuntu upgrades get quite the amount of testing that windows service packs do. Generally, you might count yourself lucky if it just works. Most people I know that use Ubuntu prefer the good old format + clean install approach. I know I have certainly dist upgraded many Debian and ubuntu installs to the point where that indeed seemed the easy way out. Windows XP on the other hand seems reasonably well behaved with service pack installs. At least I don't recall ever running into major problems with service packs of either windows 2000 or XP. The reason is that these were designed and extensively tested to be installed on existing installs.
So my comparison is entirely fair. But to be completely fair, my 2.5 year old laptop was already running sp2 when I received it. You see, it was released in 2004. Of course the upcoming SP3 is long overdue but I'm not anticipating major problems there.
Ironically, the previous and soon to be abandoned LTS was released just a few short months before Vista was released. I've been running XP through basically the entire lifespan of Ubuntu, most of which became abandonware shortly after release.
It strikes me as odd that MS is getting bad press over discontinuing support for something when all of its competitors (including Apple) maintain vastly shorter update cycles and basically force their customers into frequent update cycles. Ubuntu did the 6.04, 6.10 (LTS), 7.04, 7.10 and soon 8.04 releases in the 2.5 year lifespan of my IBM/lenovo thinkpad. It's not scheduled to be replaced until after 8.10. So this series includes two LTS releases, one of which will be obsoleted before my new laptop arrives. So theoretically (since there was no such thing when I got my laptop), the last LTS release it could have been prepackaged with was 5.04 (aka 1.0?) and I would have had to go through two major OS upgrades in the normal lifespan of my laptop just to get a decent level of security patches/important fixes and support from Ubuntu.
I'm not saying XP is great (it isn't) but I have used it on four different work desktops since 2000 without too much hassle and it is basically still getting the job done.
Gnu's Java compiler (not a full vm as far as I know) doesn't pass Sun's test suits as far as I know. There are quite a few VM implementations around and the ones that Sun actually allows to use their trademark all pass extensive sets of testsuits. Things like gnu classpath and apache harmony are very compatible as well (although not yet 100% complete implementations) of the API as well. That still leaves some room for incompatibilities but these tend to be very minor. There's no such thing for C++. There's just the specification which despite all the hard work has many ambiguities and lacks a widely used reference implementation. This leaves the door wide open to implementation differences. Things have been improving of course but it isn't even close to how different Java vms are compatible.
In any case, idealism aside, there's no good technical reason I'm aware of to use the Gnu JVM. It's slower, less scalable, has more bugs and implements less of the standard. Even the license ceased to be an issue some time ago. You are better of running e.g. the Sun compiler or one of the commercially available VMs such as JRockit or the IBM JVM. Red Hat maintains a nice branch of the official Java code that is 100% free of the few remaining closed source dependencies (beer & speech).
Yep, smalltalk definitely deserves credit here. It still has some nice characteristics over Java.
Arguably the main contribution of Java has been bringing all the smalltalk goodies to mainstream (finally). Some compromises were made along the way but the overall result is still pretty nice.
That's why you shouldn't have set your classpath as an environment variable but using the commandline; via declared dependencies in the jar file or using something like OSGI.
... Apples and oranges, nuff said.
As far as I understand, python 2.2 and 2.5 are quite far apart and 3.0 will break language and platform compatibility. It kind of matters which python you have. Good luck with the version from 1995. I happen to run into this a lot because pys60 is based on 2.2 which means that most third party stuff doesn't work there. Thanks to dynamic typing you find that out when things break or don't parse.
And perl, please
I actually know what I am doing when messing with Java and it also helps that I actually understand (and even appreciate) how the classloader works (another quite brilliant design decision from SUN), so no this has never been an issue for me. I'm quite handy with tomcat and yes, I've worked on real and I might say pretty obscure systems.
Basically all it takes is having a clue and setting up your build and deploy environment properly. Clueless idiots manually copying libraries to what they think is the right place is indeed a nuisance. Any idiot can break any system. As for debugging, I actually kind of like attaching to a JVM and inspecting what is going on in full detail (remotely). I don't know of many other systems that allow me to do that.
What Java version hell?! It's perfectly backwards compatible (binary and api, minor API bug fixes and deprecations aside). I've been developing on it since 1995 so I have some idea what I'm talking about. I think Java is probably one of the cleanest evolving platforms around (given the massive changes to it since 1995). Compare this to linux where binary compatibility is routinely broken for minor compiler version increments or libc updates. Compare this to C++ which didn't even have a widely endorsed spec until this millennium and continues to have many incompatible compilers (never mind the APIs, I'm just talking about the language semantics here). Arguably, C++ is still a mess.
.Net. Their execution is less than perfect, however. Basically an old Java 1.4 hotspot VM still kicks the CLR's ass easily. In terms of scalability and performance there is really no contest between the two. Nevermind, later versions. However, the CLR design is interesting in some respects and some of the stuff MS has done on top of it is quite innovative. But the truth is that the Java platform is still a fine piece of engineering. Many controversial design decisions taken by Sun in the early nineties around this platform are now slowly being picked up elsewhere too. Basically modern compiler architectures like llvm bring stuff that Sun has been doing for years with Java to mainstream. The whole notion of garbage collection has basically displaced the notion of manually allocating memory (except in the most conservative environments). People do web development in environments that are much slower, crappier and less secure than Java (cough php cough) because development speed is so nice to have. In short pretty much everything Java is doing on the server side has been validated through others imitating with varying degrees of success.
I think you are also wrong about virtualization. The whole point of virtualization is to abstract away OS specifics to the point where it literally is nothing more than a commodity needed to run the vm. Who cares if it is mac, windows or linux running your php/Java/ruby server? If you are doing LAMP development, virtualization is what allows you to scale your new hot web application using Amazon provided service on demand stuff. Stuff like JRuby shows that virtualization can actually be fast and scalable too (it's basically kicking regular ruby's ass). Jython is basically going the same way.
Microsoft certainly had the right ideas with
That's not really a problem, bandwidth and storage are both dirt cheap (except if you are a big ISP). 95% of it is spam anyway (technically this is an etiquette problem as well).
The problem with mail etiquette is that it requires continuous education of users which given the lack of clear benefit for them is not something you can waste lots of time on in a corporate setting (close to irrelevant from business perspective) which is why this has been a total non issue since the day people invented this mail etiquette. It sort of worked while the internet was smelly, idealistic hippies using pine/elm/or worse but after normal people started using email it quickly broke down for the obvious reason that it was basically unenforcable. This was around 1994/1995 probably. Ever since old fashioned types have been bitching about this.
As other people have pointed out, gmail does a nice job of fixing the damage to your inbox. Technology is always a better solution than mass behavior modification.
I did a pretty traditional CS study. Most of the math there was nice but I never needed much of it. I guess most I got out of it in the end is generic analytical skills. These are useful to have of course. These days there is a broad range of topics in computer science and not all of it is related to math. Probably relevance of math for the type of jobs most CS students end up doing is fairly limited.
:-).
It's funny you are claiming software engineering and computer science are two fields. I guess software engineering has been evolving into a discipline of its own. But to the best of my knowledge software engineering is still taught in the CS department of most universities as part of the normal CS curriculum.
We can argue at length about Ada and its merits and how dead/alive it is or was. Pretty pointless in my opinion and I think the job market at this point is slightly biased in my point of view. In my view the DOD type projects are niche of its own and of course the use of Ada has always been limited to such very specific niches and domains to begin with. I've never encountered any Ada software in the real world. Maybe I'm just too young (33)
And how many million programmers do you share your niche with? If you go look you'll probably find people hacking just about any language that was ever invented. That doesn't mean fortran, cobol and many of the other lovely stuff popular decades ago (including indeed Ada) isn't dead.
In general supply and demand tend to meet each other. If you find that people aren't meeting the demand (e.g. compilers for 8 bit microcontrollers) for your niche that is maybe because demand is not so strong anymore.
1. Mathematics requirements in CS programs are shrinking.
The reason is because Computer Science has developed into a discipline that is no longer pure mathematics. There's only so many courses you can squeeze into four years.
2. The development of programming skills in several languages is giving way to cookbook approaches using large libraries and special-purpose packages.
Guess what, that's what building real software is like today. We don't need people that can write quicksort in obscure unused languages but people that can grasp systems of millions of lines of code. Ada doesn't prepare you for that because it is a toy language that never really was adopted outside of the academic world. It has no good, widely used frameworks & libraries like you find in the real world. People don't use it for a whole range of software systems that you find in the real world and to prepare you for this real world there are simply much better languages around these days.
3. The resulting set of skills is insufficient for today's software industry (in particular for safety and security purposes) and, unfortunately, matches well what the outsourcing industry can offer. We are training easily replaceable professionals.
I agree that skills are important. A good prof can teach those using pretty much any turing complete language if it needs to be done. Java isn't half bad for teaching a whole lot of important CS concepts and theory. And unlike Ada, people actually use it. As for C and C++ they are useful languages to learn of course. Many colleges still do.
But of course two ex profs working for adacore are hardly objective. Ada is as dead as latin. It has some nice features but nothing you won't find somewhere else. Keeping professional skills up to date is as important for professors as it is for students. Having done a Ph. D. in software engineering & architecture and having practiced my skills in several companies, my view is that one of the largest problems in computer science education is teachers who have never worked on real, industrial sized software systems and continue to send students into industry with a lot of misguided & naive ideas about how to build software. Most SE teachers out there simply have no clue what they are talking about. Software engineering is a skill learned in practice because the teachers in university mostly lack the skills required to properly prepare students. That's the sad reality.
So basically you are telling all those companies out there considering to switch to linux that in 6 months there is going to be noone around to support whatever they are installing now?. Pretty tough message either they install stuff that is pretty much untested and might become usable over the next year or they install stuff that is pretty well tested but that nobody wants to support anymore. Sounds like Microsoft stopping support for XP when they were still beta testing Vista (which some people might argue is still ongoing). Building good quality software is about more than tossing the next version over the fence: you need to have a credible plan for the most loyal users of the old version.
The KDE people are not willing to support 3.5 for five more years (the duration of LTS support contracts of Ubuntu). That's understandable. Even Microsoft plans to end commercial support for XP before then. But at the same time, 4.0 is in no shape to make it into a LTS supported release either.
The problem here is fundamentally that release schedules of various OSS projects are poorly aligned and that that occasionally leads to regrettable delays in getting software in the hands of people. Only a small portion of users ends up using the latest and greatest. For something like a major desktop platform release, the transition period is measured in years. KDE 4.0 will take quite some time to get adopted. Now is not a good time to stuff it into a LTS distribution.
It's not only type checking but tool maturity is what really bugs me. The development tooling for dynamically typed languages is complete crap and quite literally many years behind to what Java developers are used to. I had to do some python django coding recently and sure it is a nice framework for simple stupid stuff that wasn't so hard anyway. But damn it, I'm fixing stuff all the time that normally eclipse points out when I'm typing it in Java. Stuff like "this identifier is nowhere to be seen on the imports, shall I fix it for you?". It's trivial to fix of course but it just sucks finding it out at runtime, having to fix it manually and never knowing for sure if you've covered all the code paths. When doing java development in eclipse, I just ctrl+1 + enter, or ctrl+shift+o (organize imports), or ctrl+s (I have organize imports automatically run on save). I don't actually have to think about importing stuff. That's just one example. Of course I'm using the python plugin for eclipse but it seems to be quite buggy and it only half works.
:-).
Amazingly, many python programmers settle for seventies style tools (editor + console) and completely rely on the interpreter & reality to point out what they did wrong this time. That is just stupid.
I've been going through a edit, restart django, hit F5, analyze the stupid shit it throws at me this time cycle non stop for weeks now. I haven't had to do that in years, and it isn't fun. It makes me waste shitloads of time typing stuff I usually ctrl+space and running into whole categories of bugs and issues that I'm normally stopped from introducing. It doesn't help of course that all exceptions fall through forcing you to first experience problems before you fix them. And of course most exceptions take some very specific circumstances which is why the web is full of web pages that were clearly the result of some uncaught exception.
Additionally, I miss all the goodies that come with (or can be plugged into) a good Java IDE like static code analysis (metrics, common bug patterns, bad practices), good refactoring support (PDT has some but it is buggy), code templates (like generate a nice for loop on this array or put a nice try catch around this line with all the right exceptions caught) quick fixes, guaranteed executability if the IDE doesn't complain (not the same as correctnees of course). And that's just the stuff I actually use regularly. There's also things like debuggers that you can attach to a server, remotely; monitoring and management tooling built into most decent Java application servers, profiling tools that tell you where the bottlenecks are in your running software, etc.
For me the only real value of languages like python and ruby are the expressiveness provided by functional programming like constructs you don't have in Java (currently). These are kind of nice to have. Programming the same stuff in Java takes a few more lines and extra lines of code are more bugs (statistically bugs / LOC is more or less constant so more LOC = more bugs). Java programs are measurably larger in terms of LOC compared to python or ruby, just like they are measurably much smaller when compared to C/C++. This difference in size means you get better productivity and less bugs. But the tooling just needs to catch up with this century. If dynamic typing is the reason that can't be done: fix the bug and remove it already.
Smart tools mean more time for the real work. If I need to do real work, I use something like Java or something with similarly capable tooling (technically that is more and more a hypothetical language, you might argue C# has some of the goodies here).
BTW. I'm aware of progress being made here. I played around with ruby in netbeans 6.0 a few days ago and it was looking quite good. It even automatically upgraded railse to 2.0.1. Nice. All on top of JRuby of course
QR codes are not just about advertising. They're just a quick way to get small bits of information into your phone. There's lots of use cases aside from advertising. For example, you could print one on your businesscard or display one on a website. A QR code on a business card could contain a url to a vcard (or the vcard itself). So basically to add someone to your contacts, just point the phone to the business card and snap. Same with any url.
The killer use case is not having to type in stuff on your phone. Urls on phones suck: they don't fit on the screen and typically take 30+ keypresses to type in. So currently that means if you see a url that you might want to check out, you have to write it down or remember it and then much later (if you don't forget) you might check it out on your PC. In most cases that means you are not going to bother at all.
Of course, printing QR codes is only one usecase. You can also just display them on a screen. I use a firefox extension (mobile barcoder, http://www.sample.org.uk/blog/?action=post&post=mobile_barcoder) that converts the url in the addressbar into a QR code. Whenever I want to do something with a URL in my phone, I just hover my mouse over the thing, snap and done. This works great.
You're wrong. The basic problem of browser developers vs. armchair standardization experts is that unless browsers render most pages as intended, users will use something else. That is kind of a hard reality that you can't ignore if you are serving up Firefox, Safari or Opera to millions of users. If they'd get strict about the current standards, the web would break down in their browsers. One of the HTML 5 guys (Ian Hixie) at Google has analyzed millions of pages and his conclusions are: 95%+ of the web is broken in some way; mime-types are an unreliable way to detect content-type and most document DTD headers are in fact incorrect or misleading in most cases and redundant at best (because version is also specified in html tag in correct documents). Browsers have to deal with this reality. Besides, DTDs are an obsolete mechanism that has long been replaced by more powerful schema languages.
The HTML 5 spec is being written and pushed by browser vendors. Html 5 is being supported as it is being written. It's being designed with sound engineering principles in mind: don't needlessly break existing content; provide forward and backward compatible ways to add new meaningful features (which after a decade of complete stagnation is very welcome) and precisely define semantics of the language as well as its processing and handling of incorrect html (in a way that consolidates browser behavior). This is a very pragmatic approach to improving the web and the effects are visible today in that an increasingly wider set of features works across latest versions of all major browsers. A sound principle of any kind of data processing application is to be strict about you send and very flexible about what you receive.
Most of the proposed changes in HTML 5 are very pragmatic and easy to support by browser vendors. They drop DTD support because it has proven to be completely useless and unreliable in the current web. Namespaces require something that no browser implements in the HTML rendering pipeline (full XML support). Compound documents are possible without them. Besides, HTML has links for a reason. Why embed stuff if you can link it? Html 5 is designed such that HTML 4 users can migrate to it easily rather than having to completely start from scratch. In other words it doesn't break any of the thousands of tools and content management systems out there and instead works with them. HTML 5 is also designed to degrade gracefully in browsers that don't support it so that HTML 5 content providers don't have to worry about supporting old browsers.
XHTML is not a successor but a competitor to HTML. It requires a completely different browser architecture to handle properly. Most browsers that currently handle XHTML at all have to fall back to slower rendering engines with features like incremental rendering not implemented. Basically serving up XHTML as application/xml mime type is a bad idea for this reason alone. HTML 5 is not about every browser vendor starting from scratch but about them adding useful features to a 10 year old architecture. To the armchair XHTML evangelists this might seem to be a non argument. But then armchair XHTML evangelists can't be bothered to write a proper XHTML browser that everybody wants to use either.
YANAL but I had some IPR trainings where this kind of stuff was discussed at length.
Technically copyright applies automatically in most countries. The act of creating something means copyright is granted to you on the form (i.e. not the idea like in patents). Licenses (free or otherwise) are designed to grant you rights and/or restrict rights. This can take the form of "do whatever you want" (e.g. MIT license); contracts specifying in legal terms your rights and obligations (e.g. most commercial licenses, apache and epl) or copyleft licenses (e.g. GPL) that try to negate copyright and turn its restrictions into freedoms.
In other word without a license normal copyright applies and you are legally required to get explicit permission to do things with the code (like using, copying, redistributing, etc.). Of course you could argue that such permissions are implied by posting it to a public forum. Legally it is a bit a grey area and you might wonder whether the person posting the code is actually the copyright owner. The nice thing to do is just try to contact the person who published it. More than likely they'll be happy to help you out.
Of course there is the practical side to things and it is pretty unlikely you'll ever be sued for this. Reusing small bits of code that people post on the net is pretty common. That's how the whole GNU thing started. The legal framework of the GPL and other licenses emerged as this practice became more widely spread because various people & companies were starting to apply copyright law and restricting people's rights.
That's true in theory but in practice most C programmers have no clue about underlying hardware architecture so 100% control amounts to random and arbitrary optimizations (and sometimes dangerous/counter productive) in most cases. The VM that the hardware presents to the compiler is not that different from the bytecode VM Java presents only more complicated, full of legacy features that no longer make sense and implemented in hardware. Underneath the processor translates to its real processor architecture which is probably quite alien to what most programmers are used to.
Also C programmers can only optimize for so many platforms and the optimizations can be different and even conflicting for each one. With a optimizing JIT, you can automatically optimize at run-time and apply any appropriate platform specific optimizations it knows about as well as optimizations that take into account measured performance of the running application. Doing the same in C requires dozens of different binaries and source code level optimizations just to target recent variations of X86 processors. Linux distributions have only recently started defaulting to 586 or 686 code instead of 386 code.
That's why a new compiler architecture is under construction (LLVM) that can do similar run-time optimizations to what Java is doing today. It makes sense to do optimization at run-time, also for C software.
By design that is not possible. But you might run into an exploitable bug in the native code of the vm that allows people to bypass security measures. This is true for any native software on your system. These exploits are getting pretty rare in Java though and I can't actually recall any major Java related exploits in recent years. There have been security related patches of course from Sun and most of them for good reasons. Additionally, you could install a Java application with bugs that are exploitable (but you can write buggy software in any language of course).
But by design Java is more secure than a typical native application because it protects against most memory and pointer related bugs that are used for installing worms or viruses. Additionally there is a security mechanism that provides fine grained access over which parts of the APIs are accessible to developers. This mechanism is used in applets to prevent developers from doing things you wouldn't want them to do. I'm not aware of any major applet related exploits in recent years and aside from flash and pdf, Java is still one of the most common browser plugins.
Browsers are of course a common vector for all sorts of malware but Java is rarely the cause of the misery. More common is buggy javascript parsing (by the browser); poor handling of URLs and other bugs in the decade old rendering architectures of IE and Mozilla which both are full of obscure C and C++ code that nobody really understands in full. Mozilla has spent the last two years re-architecting their browser backend to refactor memory usage and get rid of countless memory leaks, bugs and other things that didn't entirely work as designed. They did some great work there. So if you are comfortable running that on your system it would be downright irrational to have any concerns running Java. Your system is only as secure as the weakest component on it. If you are running windows 9x, it doesn't really matter what you install on it from security point of view.
BTW. Inherent security of the Java platform is also a good reason to run many serverside scripting languages inside a Java VM. For example Php has a history of many exploits, many of which simply don't work inside caucho php port to java (http://www.caucho.com/). Similar advantages apply to using jruby instead of ruby. And of course you might be able to gain a little scalability and manageability.
The concept of Miro is appealing: having videos you are interested in download automatically and have them available for watching. Miro tries to do this. The problem is that it is a mediocre feed reader; a mediocre bittorrent client and a mediocre media player. Consequently it is not replacing any of these on my machine.
Unfortunately there is lots of rough edges that are known but not addressed in this 1.0 release. For example, Miro hogs bandwidth on my PC. Because it is hogging bandwidth, forget about doing things like browsing the web or accessing the miro guide when it is running. In other words, it renders the connection unusable. Most p2p clients have options to configure and constrain upload and download bandwidth capacity. I've never used a p2p application that worked without providing reasonable settings for such options (like a few kilobytes below the max capacity for upload and download to prevent being throttled by the ISP router). Miro lacks these options. I have a ordinary cable internet connection similar to what most home users would have, nothing special. So likely this affects most users.
Additionally, I don't like the built in media player. VLC is nice if you can configure it properly but that is not possible with the options screen in Miro. There's no option to launch video in an external media player.
Finally, many options default to rather annoying settings. For example subscribing to a feed results in Miro automatically downloading all new items in that feed. That just sucks unless you subscribe to only a handful of feeds. Basically it results in the automatic downloading of stuff you'll never watch and the delaying of downloads that you might actually want to watch. Additionally no way to prioritize here of course.
Altogether this feels like a premature release. They should have spent a bit more time polishing and fixing obvious issues.