The argument that its expensive to do a return mission was dealt with by the book "Mars Direct" by Robert Zubrin. The question of Mars has come up several times on Slashdot, but never is it really understood that Zubrin worked out most of the mechanics of refueling on Mars long ago. Even more importantly we now have evidence of water - meaning the last requirement for fuel - hydrogen - is in plentiful supply on Mars, thus we don't need to import it. In other words to CO2 atmosphere and fozen water can be made into methane to use as propellant for a return journey. The only requirement is a small nuclear reactor and a lander.
Zubrin outlined a strategy of flying the return spacecraft to Mars first for a soft touchdown. The onboard nuclear power plant would then generate power to synthesise CO2 and Hydrogen into Methane to be used as fuel. Thus the return spacecraft can be fueled up ready and waiting on the surface before the astronauts even lift off for Mars. We could even test this approach with a Mars sample return. We already have excellent rover technology for sample collection.
Zubrin also talks about the Moon as a siren - the moon has less resources than Mars, and in terms of Delta-V (that is energy requirements) Mars is not that much different than the Moon. Thus going to Mars ain't that harder than the Moon. The Moon has less to offer though, and is less hospitable. At this rate we won't see humanity on another planet in my lifetime. And all it would take is a expenditure equal to less than a quater of the Iraq invasion and occupation.
Think about that - a whole new planet available for the taking for less than the cost of a small war. A bargan at twice the price.
I'm a Neo1973 Owner - and am totally gutted that OpenMoko never reached a stable usable version. That is - a version which you can install and just have it work. The reason was that their focus was on the geeks like us; that they didn't focus on delivering something like Android. In this respect I think that the focus of Android is spot on. First and foremost it's for users, not developers. However, it doesn't have the lock in and control that Apple does. In this important respect I think Android has struck a good balance between the needs of users and developers.
It looks like there was no private conversation between Linus and Alex. Alex says in his email that he was working on it, so it would seem that he did recognise that the regression was an issue. I know how he feels - sometimes you just need a break. Besides, developers like new challenges, nothing worse than maintaining the same codebase year in year out. Linus on the other hand was right to insist that regressions get fixed.
Its only your favourite language if you are incapable of objective comparison. An old friend of mine had a saying - "Horses for courses" - meaning that a language is only "best" in a certain context. If you are doing business applications chances are that C++ will take ten times as long as using Java, Delphi or C#. However, if what you want to do is introduce a student to programming you need to be able to teach each concept in isolation. That can't be done in many languages. Python is the front runner I think because it is similar to the old BASIC language in that it allows very simple programs. It is unlike BASIC however in that it does have OO principles once you understand the BASICs. Sorry.
Being a professional software developer who works in Java, and a former nightclass teacher of Java I can say without reservation that Java is NOT the best first language. Java forces you to use Object constructs from the get go. These things get in the way of communicating the principles that you want to teach. Say you want to discuss IF statements, instead of writing this:
a = 5 if a>7:
print "a is bigger than 7" else:
print "a is smaller or equal to 7"
you need to write something like
public class Example{
public String main( String[] args ) {
int a = 5;
if( a> 7)
{
System.out.println("a is bigger than 7");
} else {
System.out.println("a is smaller or equal to 7");
} }
How different is this? Well, first of all you have the concept of a class, which you can either gloss over or explain in full. Students don't know off the bat what is important and what isn't, so the class details obscure the point being made about conditional constructs. Second, the System.out.println lines introduce several ideas, such as Classes (again), the differences between classes and instances (objects) and what methods are. The first example is Python, the second Java. In summary, Python is a far better language to start with because you can teach concepts in isolation.
Java is still my favourite professional language, and to be sure it isn't a knarly twisted mess like C++, but it still isn't the ideal language to introduce students to.
The insanity of this article is that "Cloud Computing" has essentially been enabled by open source. Cloud computing is essentially putting huge data centres together with an architecture which supports massive parallelism. Hardware is cheap these days, but software before open source was expensive. And in the case of the OS that ran on that cheap hardware unreliable. Open Source has been the core enabler of companies like Google. Without technologies like Linux to build on Google and Amazon would not have been able to build out the infrastructure they have economically.
So what is this article saying? Well it seems to be saying that Open Source Vendors will not win in the Cloud space. Which is kind of an odd thing to say really, because Red Hat doesn't compete with the Googles and Amazons of the world. Once again we see the blinkered view that something is only worth anything if it can be sold for a pile of cash. The real power of Open Source isn't that some company can make a pile of cash by selling it; its that a pile more companies and individuals can save money by using it. How much money? Enough to allow the Googles and Amazons of the world to actually make a dollar themselves rather than shovelling it into software vendors.
As the article points out; there are some very serious software offerings that will help enable cloud computing - SpringSource dm Server being one of them, and OSGi in general. As discussed on slashdot earlier we need to start thinking about how to deal with data in a decentralized decoupled way in order to enable massive parallelism and redundancy.
Oh, and I may not make autonomous planes, but I do make autonomous boats, so this is more than talking out my ass; I've actually built this kind of kit.
Its not like you have an ulterior motive in trying to justify the cost the products your company makes huh. At 25K per plane I would like a bit of that action.
Okay, so get a phone like the Neo or gPhone - $400, hook up the Servos via USB and a PhidgetController - $200 - and write some custom Python code to make it all hang together. Put it all in a stock Model airplane - $150 -and you have an autonomous model aircraft. Oh - and the phone means you have GPS and GPRS for navigation and control.
Of course, there are many peaceful purposes for such systems, and it certainly won't carry much of a payload if evil is your objective. And to be honest the evil terrorists seem to do okay with cars and raw explosives. Spending time to make dinky little model planes into weapons doesn't seem high on their to do list.
Of course, using GPRS isn't going to work in the countryside of Iraq. Then you need something better - but $5K is still pretty high end.
In 1999 I was introduced to Linux. I got a copy of Caldera 2.2 and bought a new machine to try it on. There was a fair amount of pain to get Apache and Tomcat up and running, but after a couple of weeks I had a working system.
I had to leave it alone for three months after that, and figured that it would crash after a few days, a week at most. So I come back to it, and its running fine. Suddenly my thinking changes. Previously I thought it was the computers themselves that were unreliable. Turns out it was the OS - Windows - all along.
In 2002 my primary machine - a Windows box - got a virus. I had to decide whether I would reinstall Windows or make the move to Linux on the Desktop. I installed Red Hat 7.2 I believe, and never regretted it. I still use Windows for a few tasks though - video editing.
Fantastic Opportunity, Failure to Execute
on
No More OpenMoko Phone
·
· Score: 4, Insightful
The Buzz generated by OpenMoko was huge; several people at my work were just waiting for something that could be used as a phone before they purchased one. We waited three months, then six months, and then finally gave up expecting anything. That was a year and a half ago.
I got the Neo 1973 and used it in my autonomous boat project, as it had GPS, GPRS, could run Python and connect via USB to many types of devices. At this point while late there was still some promise.
One issue was the desire to please the techies. In order to be a real success it would always have needed to operate well as a phone. It never really achieved that. I would have preferred to see development limited to providing basic phone functionality first, then once that was stable extending it.
Instead it seemed that the Neo became a techie plaything, which was cool for me wanting a small device for my robotics, but not so good for a company trying to compete in the phone market where millions of units are sold. OpenMoko didn't deliver working software. The first rule of Open Source is to deliver something that works early.
Although there is a community around OpenMoko I suspect it will move to platforms that have a real future on mobile devices now. The Android platform may not be perfect yet, but it holds far more promise as a polished product that techies can extend, yet is still a viable mass market phone.
Personally I feel that Sean was too idealistic, and that OpenMoko needed someone stronger that could make some hard headed business decisions rather than making decisions that would see the total reworking of the platform when the first one wasn't even working.
I am very disappointed that such a great opportunity has failed because those in charge misunderstood that the tech people were his market. Certainly a healthy community is a good thing, but you can't create a polished product by trying to please every man and his dog.
Step aside Waterfall, move over Extreme Programming, there is now a software development process that is popular as it is effective. Yes, Avalanche Development Process will be sure to bring your project to a conclusion quickly and effectively. Read on to learn about this new and upcoming development methodology.
The Avalanche software development process occurs though several stages. In some ways this is similar to Waterfall, but more aggressive. Instead of a calming waterfall we want a Avalanche of productivity. Lets look at how it works.
Project Initiation Phase
In the initiation phase of a project your role as project manager is to secure the largest budget possible. Executive management will however be aiming to reduce your budget to the maximum extent possible, In fact if senior executives had their way you would probably be lucky to get some four by twos to make your own abacus.
It is therefore necessary to be creative in your justifications for the huge budgets you will require. First you must exaggerate almost beyond credibility the benefits to the business of the project. One way to establish the benefit to the business is to perform a Return On Investment Analysis, or ROI. Some project managers spend significant effort doing research and analysis for a ROI. The Avalanche Process has streamlined this process by skipping the analysis and going directly to the conclusion.
You can safely add your unsupported ROI conclusions in the form of an 'executive summary' to random pages from previous projects. No executive ever reads the detail of an ROI primarily because they already know you are a lying weasel. The senior management will then approve your project expecting open ended functionality with half the budget and half the projected schedule described in your project proposal. They do this knowing you have already accounted for this when you wrote the proposal.
Actually this is pretty reasonable. If it isn't possible for Google to monitor the content being posted the only alternative is to block Italy from accessing the offending services and content. State that you are being responsive to the concerns of Italy, and then watch the Government crucify those responsible for bringing charges.
I agree that Fedora should have been more responsible for including it, however the KDE team also has responsibility to ensure that something called a General Availability release is up to standard.
If something is marked as Beta or Alpha most people understand that its not fully functional and needs more testing. That's fine, because users consent to using the software on that basis.
I'm really talking about releases for general use that people have come to know and trust. For example, if Firefox was released with a new rendering engine that failed to render 15% of web pages there would probably be some explaining to do; and saying "well, it's free - you should be happy for getting anything" isn't the attitude we need.
Software in development - totally different story. Although even in software in development you expect functionality that exists not to be totally riddled with obvious defects.
Which isn't exactly the same thing, and probably not many people at KDE will be all that surprised. KDE4 is new, it has teething problems. It was risk, but we'll find out later if it was a risk worth taking.
You don't roll out half baked software over the top of working software. If KDE 3.5 was working for people releasing something that would cause users significant grief is simply irresponsible. We are beyond the days where Linux users were all geeks who used Linux as a learning platform, and who wouldn't care too much about broken features.
Linux is now being used seriously by people in their day job. Yes - Linux is "free" - but it is also such a vital piece of infrastructure that there is an expectation that delivery is equal quality OR BETTER THAN commercial alternatives. Open source should be an evolutionary process - you don't expect things that were previously working to become broken.
However, this whole "start fresh" idea has occured several times. It can potentially kill a project. It is not unique to open source, and every time I've seen it done its been done badly. Is it harder to refactor an existing application into shape? Yes. However, refactoring tends to be far less painful for users who will have a working system throughout.
Some people claim that if users want to keep using the old app they can. This is true, except in open source people will tend to abaondon applications not in active development. Although a new "fresh" version is on the way a project in this state looks to the external world like an abandoned project.
I know one project that took over three years to rewrite a vital library. The old version worked, but had bugs. The bugs were going to be addressed in the new version, but it took so long to do that we were forced to find something that was actually maintained.
Open source isn't a toddler any more. It has grown up, and people now depend on it. We cannot afford to be using users as our QA department. We could afford to do this in the past, and certainly there is are still hackers who don't mind installing the latest builds, but we cannot assume that all our users are going to be grateful for whatever we ship. It must be quality.
I violently disagree. Yes, the quality of coders is important, but process is also critical. Most shops I have worked with have a good grasp of development process. In my last position we had a very good idea of project progress based on burndown charts. We had determined what level of quality we were aiming at, and had processes and people in place to ensure the quality was achieved. We had automated test processes run every night, and testers that developed new test descriptions. While not every company is this well resourced every company I have worked for in the last decade have had quality processes.
New processes like Agile are not excuses for sloppy coding. In fact it is the opposite; the pwe may not be bogged down in paperwork, but the processes we follow are more rigorous and followed by development teams. Some practises in use now that were not in the early days of PC development: Source code version control, code review of all code, unit tests, daily build and test, planning game, iteration planning, daily check ins, and many others.
Hard Drives are great backup devices. Unlike tapes they don't stretch, and can be easily verified. Picking out specific files is far easier than with tape.
However, Mirroring is NOT a backup. In the commercial backup system I wrote I was responsible for a postgres database. Every night a cron job would do a local SQL dump to a file. This file would then be zipped and archived to several other computers, some of which were offsite.
We also had many large files, which were not stored in the database. For these files we used rsync configured in such a way that files could never be deleted. Generally files didn't change once generated. The database zip file was named based on the date, and a complete copy kept for each day.
It was a very brute force way of doing the backup, but had massive redundancy. Several computers at various locations would need to be comprimised or destroyed to destroy the data. The scripts and permissions were such that an attacker could not get universal access from one point.
I do worry about systems like GMail - and how they store and back up your data. I have invented various decentralized backup systems, so I assume that larger organisations use a similar approach - that is redundant data on many hard drives.
A while ago I wrote an article. People worked on the text, making additions and deletions, but at some point the text was simply deleted. The original idea of Wikipedia was that anyone could participate, but this is now far from the case. Only Wikipedia specialists can participate. Those who wish to actually write articles must go through a in depth training process; otherwise their input is deleted.
So whatever; not going to support them by funds or effort. My life doesn't revolve around Wikipedia. If they really wanted the input from me or others they would be less hostile.
I suppose I am concerned that what is becoming a source of authoritive information is being controlled by a bunch of egotists.
Yes,remote desktop software is part of Ubuntu standard install, and probably many others. I use wireless, but of course you will need to test your cards. Being free it won't cost a cent.
Okay, so they have to go find a provider which doesn't protect scumbags. At most there is a little data loss and inconvenience in setting up with a new provider. If I were selling legitimate goods out of a tinny house I wouldn't be complaining if the police raided it and it was shut down. Similarly one should be careful who you host with.
New Zealand has just rolled over on the issues around DRM and ISP's being held responsible for content that they deliver - aka like the US DMCA. I strongly believe this was done in order to set up the conditions for a US free trade deal; you know like Australia did when it also gave in to US demands around Copyright and Patents.
To answer your question; right now we don't have filtering, but I wouldn't count on that situation lasting very long. It looks like the Governments of the world are taking the Chinese success in controlling its population and applying it to the "free world".
For web development I would recommend the following course of action:
a) Download Tomcat and start with writing some servlets. Nobody uses raw servlets these days, but the at at the foundation of Java web technology. Understanding at a primitive level of servlets lets you understand what has been built on top.
b) Not sure of the order here, so I would look at Struts and Hibernate and Velocity about the same time. These technologies deal with totally different problems. You might also want to look at EJB and JSP, but personally I prefer Hibernate and Velocity.
c) Most software shops will also make use of infrastructure projects such as Ant for building, JUnit for automated testing, and perhaps Cruise Control for continuous integration. Oh, and obviously you should be familiar with SVN and CVS, two popular version control systems.
d) Finally take a look at Spring, which is becoming increasingly popular.
Finally some advice; at the end of the day the value to the client is the most important thing. Many of the above projects have resulted directly from problems Java developers were facing. With that in mind make sure that you don't just use all these technologies because they are flavour of the month. Each has its place, and sometimes the overhead in using them isn't worth the effort.
It is a good idea to at least study what is available, but don't try to learn everything. Target a specific stack and perfect your skills with it.
Slashdot Mirror
The argument that its expensive to do a return mission was dealt with by the book "Mars Direct" by Robert Zubrin. The question of Mars has come up several times on Slashdot, but never is it really understood that Zubrin worked out most of the mechanics of refueling on Mars long ago. Even more importantly we now have evidence of water - meaning the last requirement for fuel - hydrogen - is in plentiful supply on Mars, thus we don't need to import it. In other words to CO2 atmosphere and fozen water can be made into methane to use as propellant for a return journey. The only requirement is a small nuclear reactor and a lander.
Zubrin outlined a strategy of flying the return spacecraft to Mars first for a soft touchdown. The onboard nuclear power plant would then generate power to synthesise CO2 and Hydrogen into Methane to be used as fuel. Thus the return spacecraft can be fueled up ready and waiting on the surface before the astronauts even lift off for Mars. We could even test this approach with a Mars sample return. We already have excellent rover technology for sample collection.
Zubrin also talks about the Moon as a siren - the moon has less resources than Mars, and in terms of Delta-V (that is energy requirements) Mars is not that much different than the Moon. Thus going to Mars ain't that harder than the Moon. The Moon has less to offer though, and is less hospitable. At this rate we won't see humanity on another planet in my lifetime. And all it would take is a expenditure equal to less than a quater of the Iraq invasion and occupation.
Think about that - a whole new planet available for the taking for less than the cost of a small war. A bargan at twice the price.
I'm a Neo1973 Owner - and am totally gutted that OpenMoko never reached a stable usable version. That is - a version which you can install and just have it work. The reason was that their focus was on the geeks like us; that they didn't focus on delivering something like Android. In this respect I think that the focus of Android is spot on. First and foremost it's for users, not developers. However, it doesn't have the lock in and control that Apple does. In this important respect I think Android has struck a good balance between the needs of users and developers.
It looks like there was no private conversation between Linus and Alex. Alex says in his email that he was working on it, so it would seem that he did recognise that the regression was an issue. I know how he feels - sometimes you just need a break. Besides, developers like new challenges, nothing worse than maintaining the same codebase year in year out. Linus on the other hand was right to insist that regressions get fixed.
Its only your favourite language if you are incapable of objective comparison. An old friend of mine had a saying - "Horses for courses" - meaning that a language is only "best" in a certain context. If you are doing business applications chances are that C++ will take ten times as long as using Java, Delphi or C#. However, if what you want to do is introduce a student to programming you need to be able to teach each concept in isolation. That can't be done in many languages. Python is the front runner I think because it is similar to the old BASIC language in that it allows very simple programs. It is unlike BASIC however in that it does have OO principles once you understand the BASICs. Sorry.
Being a professional software developer who works in Java, and a former nightclass teacher of Java I can say without reservation that Java is NOT the best first language. Java forces you to use Object constructs from the get go. These things get in the way of communicating the principles that you want to teach. Say you want to discuss IF statements, instead of writing this:
a = 5
if a>7:
print "a is bigger than 7"
else:
print "a is smaller or equal to 7"
you need to write something like
public class Example{
public String main( String[] args ) {
int a = 5;
if( a> 7)
{
System.out.println("a is bigger than 7");
} else {
System.out.println("a is smaller or equal to 7");
}
}
How different is this? Well, first of all you have the concept of a class, which you can either gloss over or explain in full. Students don't know off the bat what is important and what isn't, so the class details obscure the point being made about conditional constructs. Second, the System.out.println lines introduce several ideas, such as Classes (again), the differences between classes and instances (objects) and what methods are. The first example is Python, the second Java. In summary, Python is a far better language to start with because you can teach concepts in isolation.
Java is still my favourite professional language, and to be sure it isn't a knarly twisted mess like C++, but it still isn't the ideal language to introduce students to.
In order to answer questions about this general problem of how to become an UberG33k I have prepared the following video.
http://www.youtube.com/watch?v=jhz-RdohR8U
The insanity of this article is that "Cloud Computing" has essentially been enabled by open source. Cloud computing is essentially putting huge data centres together with an architecture which supports massive parallelism. Hardware is cheap these days, but software before open source was expensive. And in the case of the OS that ran on that cheap hardware unreliable. Open Source has been the core enabler of companies like Google. Without technologies like Linux to build on Google and Amazon would not have been able to build out the infrastructure they have economically.
So what is this article saying? Well it seems to be saying that Open Source Vendors will not win in the Cloud space. Which is kind of an odd thing to say really, because Red Hat doesn't compete with the Googles and Amazons of the world. Once again we see the blinkered view that something is only worth anything if it can be sold for a pile of cash. The real power of Open Source isn't that some company can make a pile of cash by selling it; its that a pile more companies and individuals can save money by using it. How much money? Enough to allow the Googles and Amazons of the world to actually make a dollar themselves rather than shovelling it into software vendors.
As the article points out; there are some very serious software offerings that will help enable cloud computing - SpringSource dm Server being one of them, and OSGi in general. As discussed on slashdot earlier we need to start thinking about how to deal with data in a decentralized decoupled way in order to enable massive parallelism and redundancy.
How about here:
http://www.towerhobbies.com/products/hobbico/hcaa23_n.html
Oh, and I may not make autonomous planes, but I do make autonomous boats, so this is more than talking out my ass; I've actually built this kind of kit.
Its not like you have an ulterior motive in trying to justify the cost the products your company makes huh. At 25K per plane I would like a bit of that action.
Okay, so get a phone like the Neo or gPhone - $400, hook up the Servos via USB and a PhidgetController - $200 - and write some custom Python code to make it all hang together. Put it all in a stock Model airplane - $150 -and you have an autonomous model aircraft. Oh - and the phone means you have GPS and GPRS for navigation and control.
Of course, there are many peaceful purposes for such systems, and it certainly won't carry much of a payload if evil is your objective. And to be honest the evil terrorists seem to do okay with cars and raw explosives. Spending time to make dinky little model planes into weapons doesn't seem high on their to do list.
Of course, using GPRS isn't going to work in the countryside of Iraq. Then you need something better - but $5K is still pretty high end.
In 1999 I was introduced to Linux. I got a copy of Caldera 2.2 and bought a new machine to try it on. There was a fair amount of pain to get Apache and Tomcat up and running, but after a couple of weeks I had a working system.
I had to leave it alone for three months after that, and figured that it would crash after a few days, a week at most. So I come back to it, and its running fine. Suddenly my thinking changes. Previously I thought it was the computers themselves that were unreliable. Turns out it was the OS - Windows - all along.
In 2002 my primary machine - a Windows box - got a virus. I had to decide whether I would reinstall Windows or make the move to Linux on the Desktop. I installed Red Hat 7.2 I believe, and never regretted it. I still use Windows for a few tasks though - video editing.
The Buzz generated by OpenMoko was huge; several people at my work were just waiting for something that could be used as a phone before they purchased one. We waited three months, then six months, and then finally gave up expecting anything. That was a year and a half ago.
I got the Neo 1973 and used it in my autonomous boat project, as it had GPS, GPRS, could run Python and connect via USB to many types of devices. At this point while late there was still some promise.
One issue was the desire to please the techies. In order to be a real success it would always have needed to operate well as a phone. It never really achieved that. I would have preferred to see development limited to providing basic phone functionality first, then once that was stable extending it.
Instead it seemed that the Neo became a techie plaything, which was cool for me wanting a small device for my robotics, but not so good for a company trying to compete in the phone market where millions of units are sold. OpenMoko didn't deliver working software. The first rule of Open Source is to deliver something that works early.
Although there is a community around OpenMoko I suspect it will move to platforms that have a real future on mobile devices now. The Android platform may not be perfect yet, but it holds far more promise as a polished product that techies can extend, yet is still a viable mass market phone.
Personally I feel that Sean was too idealistic, and that OpenMoko needed someone stronger that could make some hard headed business decisions rather than making decisions that would see the total reworking of the platform when the first one wasn't even working.
I am very disappointed that such a great opportunity has failed because those in charge misunderstood that the tech people were his market. Certainly a healthy community is a good thing, but you can't create a polished product by trying to please every man and his dog.
Step aside Waterfall, move over Extreme Programming, there is now a software development process that is popular as it is effective. Yes, Avalanche Development Process will be sure to bring your project to a conclusion quickly and effectively. Read on to learn about this new and upcoming development methodology.
The Avalanche software development process occurs though several stages. In some ways this is similar to Waterfall, but more aggressive. Instead of a calming waterfall we want a Avalanche of productivity. Lets look at how it works.
Project Initiation Phase
In the initiation phase of a project your role as project manager is to secure the largest budget possible. Executive management will however be aiming to reduce your budget to the maximum extent possible, In fact if senior executives had their way you would probably be lucky to get some four by twos to make your own abacus.
It is therefore necessary to be creative in your justifications for the huge budgets you will require. First you must exaggerate almost beyond credibility the benefits to the business of the project. One way to establish the benefit to the business is to perform a Return On Investment Analysis, or ROI. Some project managers spend significant effort doing research and analysis for a ROI. The Avalanche Process has streamlined this process by skipping the analysis and going directly to the conclusion.
You can safely add your unsupported ROI conclusions in the form of an 'executive summary' to random pages from previous projects. No executive ever reads the detail of an ROI primarily because they already know you are a lying weasel. The senior management will then approve your project expecting open ended functionality with half the budget and half the projected schedule described in your project proposal. They do this knowing you have already accounted for this when you wrote the proposal.
Click For More
Actually this is pretty reasonable. If it isn't possible for Google to monitor the content being posted the only alternative is to block Italy from accessing the offending services and content. State that you are being responsive to the concerns of Italy, and then watch the Government crucify those responsible for bringing charges.
I agree that Fedora should have been more responsible for including it, however the KDE team also has responsibility to ensure that something called a General Availability release is up to standard.
If something is marked as Beta or Alpha most people understand that its not fully functional and needs more testing. That's fine, because users consent to using the software on that basis.
I'm really talking about releases for general use that people have come to know and trust. For example, if Firefox was released with a new rendering engine that failed to render 15% of web pages there would probably be some explaining to do; and saying "well, it's free - you should be happy for getting anything" isn't the attitude we need.
Software in development - totally different story. Although even in software in development you expect functionality that exists not to be totally riddled with obvious defects.
Which isn't exactly the same thing, and probably not many people at KDE will be all that surprised. KDE4 is new, it has teething problems. It was risk, but we'll find out later if it was a risk worth taking.
You don't roll out half baked software over the top of working software. If KDE 3.5 was working for people releasing something that would cause users significant grief is simply irresponsible. We are beyond the days where Linux users were all geeks who used Linux as a learning platform, and who wouldn't care too much about broken features.
Linux is now being used seriously by people in their day job. Yes - Linux is "free" - but it is also such a vital piece of infrastructure that there is an expectation that delivery is equal quality OR BETTER THAN commercial alternatives. Open source should be an evolutionary process - you don't expect things that were previously working to become broken.
However, this whole "start fresh" idea has occured several times. It can potentially kill a project. It is not unique to open source, and every time I've seen it done its been done badly. Is it harder to refactor an existing application into shape? Yes. However, refactoring tends to be far less painful for users who will have a working system throughout.
Some people claim that if users want to keep using the old app they can. This is true, except in open source people will tend to abaondon applications not in active development. Although a new "fresh" version is on the way a project in this state looks to the external world like an abandoned project.
I know one project that took over three years to rewrite a vital library. The old version worked, but had bugs. The bugs were going to be addressed in the new version, but it took so long to do that we were forced to find something that was actually maintained.
Open source isn't a toddler any more. It has grown up, and people now depend on it. We cannot afford to be using users as our QA department. We could afford to do this in the past, and certainly there is are still hackers who don't mind installing the latest builds, but we cannot assume that all our users are going to be grateful for whatever we ship. It must be quality.
I violently disagree. Yes, the quality of coders is important, but process is also critical. Most shops I have worked with have a good grasp of development process. In my last position we had a very good idea of project progress based on burndown charts. We had determined what level of quality we were aiming at, and had processes and people in place to ensure the quality was achieved. We had automated test processes run every night, and testers that developed new test descriptions. While not every company is this well resourced every company I have worked for in the last decade have had quality processes.
New processes like Agile are not excuses for sloppy coding. In fact it is the opposite; the pwe may not be bogged down in paperwork, but the processes we follow are more rigorous and followed by development teams. Some practises in use now that were not in the early days of PC development: Source code version control, code review of all code, unit tests, daily build and test, planning game, iteration planning, daily check ins, and many others.
Hard Drives are great backup devices. Unlike tapes they don't stretch, and can be easily verified. Picking out specific files is far easier than with tape.
However, Mirroring is NOT a backup. In the commercial backup system I wrote I was responsible for a postgres database. Every night a cron job would do a local SQL dump to a file. This file would then be zipped and archived to several other computers, some of which were offsite.
We also had many large files, which were not stored in the database. For these files we used rsync configured in such a way that files could never be deleted. Generally files didn't change once generated. The database zip file was named based on the date, and a complete copy kept for each day.
It was a very brute force way of doing the backup, but had massive redundancy. Several computers at various locations would need to be comprimised or destroyed to destroy the data. The scripts and permissions were such that an attacker could not get universal access from one point.
I do worry about systems like GMail - and how they store and back up your data. I have invented various decentralized backup systems, so I assume that larger organisations use a similar approach - that is redundant data on many hard drives.
Shut up and get back to work.
I'm Peter, and I'm an internet addict.
A while ago I wrote an article. People worked on the text, making additions and deletions, but at some point the text was simply deleted. The original idea of Wikipedia was that anyone could participate, but this is now far from the case. Only Wikipedia specialists can participate. Those who wish to actually write articles must go through a in depth training process; otherwise their input is deleted.
So whatever; not going to support them by funds or effort. My life doesn't revolve around Wikipedia. If they really wanted the input from me or others they would be less hostile.
I suppose I am concerned that what is becoming a source of authoritive information is being controlled by a bunch of egotists.
Yes,remote desktop software is part of Ubuntu standard install, and probably many others. I use wireless, but of course you will need to test your cards. Being free it won't cost a cent.
Small island off the coast of NZ perhaps?
Okay, so they have to go find a provider which doesn't protect scumbags. At most there is a little data loss and inconvenience in setting up with a new provider. If I were selling legitimate goods out of a tinny house I wouldn't be complaining if the police raided it and it was shut down. Similarly one should be careful who you host with.
New Zealand has just rolled over on the issues around DRM and ISP's being held responsible for content that they deliver - aka like the US DMCA. I strongly believe this was done in order to set up the conditions for a US free trade deal; you know like Australia did when it also gave in to US demands around Copyright and Patents.
To answer your question; right now we don't have filtering, but I wouldn't count on that situation lasting very long. It looks like the Governments of the world are taking the Chinese success in controlling its population and applying it to the "free world".
For web development I would recommend the following course of action:
a) Download Tomcat and start with writing some servlets. Nobody uses raw servlets these days, but the at at the foundation of Java web technology. Understanding at a primitive level of servlets lets you understand what has been built on top.
b) Not sure of the order here, so I would look at Struts and Hibernate and Velocity about the same time. These technologies deal with totally different problems. You might also want to look at EJB and JSP, but personally I prefer Hibernate and Velocity.
c) Most software shops will also make use of infrastructure projects such as Ant for building, JUnit for automated testing, and perhaps Cruise Control for continuous integration. Oh, and obviously you should be familiar with SVN and CVS, two popular version control systems.
d) Finally take a look at Spring, which is becoming increasingly popular.
Finally some advice; at the end of the day the value to the client is the most important thing. Many of the above projects have resulted directly from problems Java developers were facing. With that in mind make sure that you don't just use all these technologies because they are flavour of the month. Each has its place, and sometimes the overhead in using them isn't worth the effort.
It is a good idea to at least study what is available, but don't try to learn everything. Target a specific stack and perfect your skills with it.