Get your employer to sign them (or whoever you need to talk to). That's the way PGP was designed to operate (and I'm sure there are still PGP signing parties going on these days). Do a face to face with them, and give them the key via USB or whatever. They sign them on their machine. Then they know the stuff is from you (much, much, much better than a CA).
The sucky part of that is that's who I get my email pgp keys from. But really there needs to be a tiered CA system, where a CA is providing certs to anyone that asks, to people that have to prove themselves, and to government and other trusted sources. The way things are now, pulling the plug on an entire CA is the nuclear option.
Why do you need to get your email pgp keys from *anybody* except yourself? There are very few transactions where someone needs to know your actual identity. Most of the time, they need to know that you are the same person they talked to last time. Meet someone online (or even IRL) and exchange keys. Now when you receive email from that person you know that it is the person you talked to previously (as long as the key exchange is not compromised). Who cares what your real name is, or where you live, etc, etc.
Even (especially?) transactions with companies don't need a CA. Does a customer *really* need to prove who they are? Or do they just need to prove that they are associated with past interactions with the company? In fact, giving more information is an invasion of privacy. Why does Amazon.com need to know my real name to sell me a book? They just need my address and some way to receive payment.
Even the other way around is not particularly useful. What do I really know about Amazon.com? Nothing except that they sell books. My friend says that he buys books on Amazon.com all the time with no problem. So what I really want to do is make sure that the site that I'm going to is the same site that my friend went to. I need my *friend* to authorise the certificate. Because who am I going to trust? My friend or some CA that I've never even heard of before?
If I go to a site that I don't know about, then the certificate is worthless. Who cares if the CA knows *who* they are. It doesn't tell me anything about how they do business. It might me slightly useful for the situation where I have generally heard about a company, but don't have a key/certificate. But in this case, I still have to trust a CA that I know nothing about.
CAs aren't particularly useful for people like me and you. What they are *really* useful for is controlling who can do what on the internet. If I don't get a signed certificate, then browsers will jump up and down screaming that I might be an evil website. That's all. It's simply a sticker that you buy saying "This is a legitimate site". Do not want.
While there isn't a lot of research on the topic, what there is seems to indicate that open source software and "commercial" (i.e. not open source) software have similar defect densities. Here's a paper on the topic:
I've worked on both "commercial" projects and opens source projects. My personal experience has been that willingness to fix bugs is much higher on the open source teams. Usually the authors actually use the product in their everyday life and bugs affect them personally. They are highly motivated to fix them. On "commercial" software projects, my experience is that the authors of the software rarely use it in their every day life. Selection of bugs to fix usually comes from a project manager.
Both open source and "commercial" projects usually have large backlogs of bugs that never get fixed. The difference is that open source projects usually fix bugs that directly affect the authors, while "commercial" projects fix bugs that directly affect customers who have bought enough units to gain the right to complain (i.e. thousands of copies). However, with an open source project, if the authors decide not to fix a bug you usually have a number of options. You can complain on the developer's mailing list and plead your case. If that doesn't work, you can fix the bug yourself, or hire someone else to do it. With "commercial" software once you file your bug you usually don't even know if they will decide to fix it. You usually don't even know if it was fixed in the next version without buying it and trying it for yourself. If the program manager decides not to fix your bug, you have no recourse at all unless you have already bought thousands of copies of the software and can threaten not to upgrade to the next version unless they fix your bug. Even then they might decide not to.
"Well that's the thing with volunteer made software isn't it?" is what you wrote. Yes. That's the thing with volunteer made software. You have direct access to the developers to report your bug. You get informed whether your bug when your bug is being looked at. You can make a case for having your bug fixed. And if that doesn't work, you can fix it yourself. What is there that needs fixing again?
There is some truth to what you say, but I think you may be overestimating the population density of Asia. For example, I live in Japan and the other day a nice salesman from NTT (the state run telephone company) showed up to tell me that fibre was available in my town. For less than 5000 yen per month (about $60?) I can get a 200 Meg connection. I live in a small farming town with a population of about 25K. My prefecture (Shizuoka) has a total population of 3.7 million and a population density of 485 people per square km. The largest city in my prefecture has only 800,000 people. The terrain is mostly mountainous and we have regular earthquakes greater than 6.0 in magnitude. To top it off we also have several typhoons every year.
In contrast New York state has a population of over 19 million and a population density of 408 people per square km. Its largest city has more than 8 million people and has a population density higher than that of Tokyo. The terrain is similar to that of where I'm living, but there are rarely any large earthquakes and hurricanes mostly blow themselves out before they get that far north.
The thing is, I have no bandwidth caps and if I am to believe the nice salesman's charts, they actually have enough bandwidth to supply the connection they are giving me (i.e., they *aren't* over subscribed). I've had 3G on my Android phone for the last year as well and tethered to my laptop I can always get 400K download rates on FTP. And like I say, the only thing around here is surfers, and tea farms.
I don't doubt that trying to hook up all of America is going to be way more expensive than hooking up all of Japan. But there really is no excuse not to have decent service in at least *some* places in the US.
Patents lock small developers out of the market. "Defensive" patents only help corporations that have lots of them. If a company says "We'll sue you over infringement of these 100 patents", the defence of "Well, you're infringing on this one patent" isn't going to be effective. Because Apple, IBM, MS, etc have a lot of patents they effectively have a stand off between them. But they are afraid of upcoming companies that come out of nowhere to take part of their market. Patents stop that because there is no way for a small company to get their hands on tens of thousands of patents. While patent trolls hurt the big companies, they absolutely destroy small companies who get targeted by them. Thus, the big companies are willing to put up with the relatively predictable legal cost in order to avoid unpredictable competition in the marketplace.
How does refactoring bring shareholder value? How does it boast the company's stock price? How does it increase revenue?.../CEO/PHB voice
By slowing down slightly and refactoring after each change, I increase the overall throughput of the development. Without the refactoring, the change comes back as quickly as possible, but over time, I get slower and slower. With refactoring, my ability to make changes is initially slower, but my rate is constant. There are two main benefits for refactoring from a shareholder value. The first is that long-term I can get more done. However, this is vastly overshadowed by the fact that with a well factored code base, my actions are more predictable. We can plan much more effectively, because my development rate is more regular. This means that sales and marketing get longer lead times and we have less surprises towards the end of the development cycle. We are able to set customer expectation a lot better because we have a very good idea of what we will deliver and when it will be delivered. R&D is less than 10% of expenditures in the average established software company. Sales is usually more than 30%. We need to do everything we can to make sales more effective, since this is where our money is being spent. Regular refactoring directly supports that action.
Or at least, that's what I've said in the past. I never have trouble making it fly.
That's why you shouldn't refactor that way. Predicting the future is hard, and even those people who think they are good at it, often aren't. It becomes a manifest destiny where they bend the new work to fit their old "brilliant" model -- in essence forgoing the refactoring in order to stroke their own ego. Refactoring should be a recurring event and developers need to understand that there is no overarching "best" design going into the future. You should refactor such that the software, as it stands now, is as simple as you can make it. When you add new code in the future, you then refactor again, to make it such that it is as simple as you can make it. Because you are refactoring constantly, the changes are usually small. Sometimes they are large, but because the code is as simple as it can possibly be, the changes are not difficult to make.
Trying to design for the future increases complexity of the software and impedes your ability to refactor, As I mentioned, you may be unwilling to give up your brilliant first design. But also, changes you expect down the road may not (probably won't) happen exactly the way you envisioned them. As you refactor to meet new requirements, you end up shifting a lot of code that doesn't even do anything, because it is only required in the (unspecified) future. This becomes a large source of errors, since your refactorings are hard to test. Usually there are complaints that the refactoring "broke" the design and that refactoring should be limited to avoid "code churn".
In order to explain the necessity of refactoring to managers, I usually explain that in development there is a tradeoff between interactivity and throughput. If you want any specific activity to finish as quickly as possible, then there is a cost to pay. That cost is throughput. My change is as fast as possible, but tomorrow I'll slow down a bit. The next day a bit more, etc. Over time, my "as fast as possible" isn't very fast any more. Instead, I try to optimise throughput on the team. I want the overall development effort to be as fast as possible. But there is a cost for that. It means that each individual change is not as fast as possible. However, the rate of changes is constant over the project (actually, it is usually slightly increasing since clean code gives some reuse opportunity -- not as much as many people think, but enough to slowly accelerate the project). Over the period of a year the throughput is higher. This is usually desired by managers (but not always -- for one-off projects, it is sometimes better to optimise for interactivity over throughput).
Another very important part about refactoring is to make it a required part of each change. Changes aren't finished when the functionality is acquired. The changes are only finished when the affected code has been refactored to make the design as simple as possible for the current functionality. There is never a line item on the todo list that says, "refactor X". Similarly, bad code that isn't used directly, or modified is never touched. We don't improve code for the sake of improvement (as refreshing as it would be). Instead you only refactor code that is directly related to your changes. In legacy systems this is difficult because you often get the "pulling a loose thread" situation; you start refactoring and quickly find that you are touching everything in the system. Usually it's a good idea to grab a couple of people and discuss the best place to limit your changes.
The result of doing work this way is to make it so that the manager never has input on whether you refactor or not. It is a technical, not strategic decision and belongs in the hands of the developer. If your manager understands that your goals are the highest possible throughput, and your manager trusts your technical decisions, then there is no problem. If this situation doesn't exist, you need to have a talk with your manager (or possibly change jobs since a manager who doesn't trust you will have no ability to manage you properly).
I think it's useful to look back at TFA. The point he was making was that R and D are 2 different things. To be fair, Microsoft is one of the few companies that actually invest in research (R), but in every software company that I'm aware of the D (development) dramatically dwarfs the R. One of the things most frustrating about software patents is that they are usually the result of refinement (if that!) of existing techniques where no real novel thought has gone into it. One could look at a company like MS and say that their high R&D costs are a result of inefficiencies in their development efforts as much as they are the result of trying to do something new (and I say that with the full realisation that MS is better than almost any software company with regard to research). Likewise, while Google also does a lot of research (comparatively), I get the impression that their R&D numbers are high mostly because they pay a lot for their developers. It doesn't necessarily follow that basic research will be done.
Now what the Libre Office guys need to do is wander up to them and say, "You're saving 40 million Kroner in licensing fees. But is there anything in LO that doesn't meet your standards? Because for a tiny fraction of those savings we'd be happy to fix the problem right away."
These used to be commonly accepted ideas before we gutted public education and Fox News began blaring propaganda 24/7.
I agree with your general principle, but I don't think you have thought this part through. If you think back, there will be a time in your life where society changed. When you were young, people followed ideals, not fear; politicians did what they believed was right, not what their donors told them to do; law enforcement worked to keep people free, not to control them. When did society change? It changed when your perception changed and it is only actually your awareness that has changed.
Not much of actual substance has changed in our lifetimes. When I was a kid (most likely a fair amount of time before you were a kid), I used to laugh at the one sided, blantant propaganda machine that was American news. I only stopped laughing when I realised that my own country's news was just as bad (just different propaganda). I laughed at the unbelievable ignorance of Americans apparently educated simply to be god fearing, flag worshipping sheep until I graduated high school and as a long time resident of Manitoba didn't know who Louis Riel was.
The problem with thinking that the world has changed is that you will focus on the wrong things. You will waste your energy railing against something that, while being a strong symptom of the problem, is not the problem itself. Instead of looking at what has changed, and trying to find what has spoiled, rather look for things that haven't changed. Look for things that were rotten from the beginning. This will give you a much better insight into the issue, IMHO.
About 5 years ago I ditched my car and replaced it with a bicycle. What hit me pretty quickly (especially since I wasn't in great shape) was that I didn't want to ride around for hours on end finding things. In a car, if you make a mistake or simply want to try a new route somewhere, going an extra couple of km is nothing. On the bike it was frustrating, tiring and at the end of it I was always worried if I would remember how to get home again (without adding an extra 5 km to my trip). The GPS made a huge difference to me and enabled me to get a better handle on if the distance was too far, etc, etc. I remember always jumping through hoops to take buses to the train station and one day I punched it into the GPS and realised that it was only 20K. After that I never took the bus again.
On the down side, the GPS always gives me the shortest route to my goal. As I live near mountains, this translates to always giving me the steepest route to my goal. It took me a while to jam that into my head. It would be nice if the GPS had a feature to avoid gradients of over 7% or so...
We haven't been overwhelmingly defensive in about a decade now.
I hate to break it to you, but the US hasn't been overly defensive for a lot longer than a decade. Korea, Cuba, the Dominican Republic, Vietnam, Grenada, Panama, Persian Gulf, Bosnia and Herzegovina. At least Korea and Bosnia and Herzegovina were part of a larger effort, so I suppose we can give a few brownie points. Of course these are only direct military interventions from 1950 to 2000 and don't include the dozens of countries where the US has funded uprisings, overthow of the government, etc, etc. Hell, the US pays Pakistan with weapons to allow it to bomb Pakistani cities in hopes of killing terrorists. These weapons are used to continue Pakistan's war with India. Things like this just make my head spin.
It appears from my perspective that US foreign defensive policy is to get actively stuck in and compel other nations to follow it's world view, using force if necessary. It is not the only country in the world to be doing this, but as the most powerful nation in the world (economically and militarily) I personally feel that its international reputation of being a bully is well deserved. That the US population feels comfortable with the idea of the US as the "police of the world" is truly frightening for a lot of non-Americans.
I've only tried briefly, but I think Compiz works fine on KDE4.5/4.6. I think it might run faster in the situations you are talking about. I've noticed the speed of kwin is heavily dependent up on the theme you choose. On my ridiculously underpowered netbook (which I like using for some reason) it can be unusably slow with some themes, but reasonable with others. Compiz seems to have more consistent performance.
Actually, the US's debt to GDP ratio hasn't really changed all that much in the last 20 years. If you compare it to other first world countries, it's reasonably fine. Even though the debt keeps rising, the country keeps making more money, so the amount of debt per income is holding relatively steady (well, slight upward climb, but not astronomical).
I didn't read TFA, but here are some thoughts to consider. printf debugging is only useful if you have an uncomplicated subsystem. You have to be able to quickly find the area where the problem may lie. You have to be able to easily identify and set up the scenario that is causing the problem. You have to easily be able to modify the code, redeploy and run it. I find that a lot of people will say, "My system is too complex for that". What they don't quite grasp is that their system is broken.
If you need a debugger to evaluate the system when it enters a broken state, your software composition is likely the fault. You should be able to write a quick script that sets up the circumstance that you are interested in. If you have to actually run the entire software to get into this situation, they you likely have serious coupling issues that you should resolve.
The same is true for tracing. Generally tracing is useful when you can't understand the code path that led to it arriving at a particular location. This probably means that either your interfaces are confusing, or you have poor cohesion. You may have issues where functions are doing more than one task, or you have many poorly factored methods that copy and paste similar code.
For me one of the biggest incentives to use a debugger is because the build system is broken. I can't set up scenarios to test because it takes an hour to build and deploy the system. Again, this could be due to coupling/cohesion problems in the software composition, but it is often just laziness when creating the build system. Having a continuous integration/build system is extremely helpful.
When you are working with a legacy system, sometimes there isn't much you can do. The pooch was screwed years ago and apart from rewriting the whole damn thing, you just aren't going to get there from here. The problem comes when the programmers don't even realise the inherent problems in their system. They have 2 million lines of horribly organised libraries and code copy and pasted all over the place. They have 200 line long (or more!) methods that duplicate functionality from a hundred other 200 line long methods. The debugger lets them do this and stay sane.
Taking away the debugger and telling them to use printfs (with no tracing subsystem!) shows them the hell that they have created. Of course, even then they often don't take the hint...
There aren't good engineering practices in software. This is why I abjectly refuse to call myself an engineer (that and I'm *not* an engineer). Can you tell me with a known degree of certainty the probability that a software component will fail? What procedures would you put into place to give you that number (keeping in mind the halting problem)? What procedures would you put into place to mitigate those failures? Because I'm drawing a big gigantic blank here.
Look, I'm all for using "Software Engineering" practices. Personally, in my career I have championed TDD, peer review, acceptance tests written in advance by someone other than the programmers, etc, etc, etc. But this isn't engineering. The best I can tell anyone is, "Hey, it doesn't break on *my* machine. Yeah, I think the probability of it breaking on your machine is 'low'. No, I wouldn't like to specify a number, thank you very much." Why do you think software never comes with a warrantee?
I often wonder what we could do to actually make this an engineering discipline. For one thing, I think we really need to invest in developing stochastic testing techniques. We need to be able to characterise all the inputs a program can take and to test them automatically in a variety of different ways. But this is the stuff of research. There are some things we can do now, but it's all fairly naiscent technology. Maybe in 20 years...:-P
Not that I disagree with you, but to play devil's advocate, where are the developers that disagree with this direction? If we're really so keen to keep what we've got, why aren't we forking? There are a lot of developers working on Gnome/KDE/etc, and they are all power users. Why are they building systems that they should hate? What's going on?
In my opinion, the problem is that *all* of the desktop environments suck. I mean, I think I started with TWM and I liked it at the time, but I would never go back to it now. I transitioned through a lot of different window managers and desktop environments and there isn't one that I think, "Yeah, that was pretty much right". Obviously if I did, I'd just switch back to it. The problem is that these new ideas generally *are* better than the old ideas, but that they are throwing out the baby with the bath water. For example, focus follows mouse has a vastly better workflow (IMHO) that click to focus. Why is it getting left behind? It's because people aren't used to it. Eventually, even I might give it up if they give me enough in exchange. But I'll go kicking and screaming all the way.
What we really need to do is to stop complaining about what is being taken away from us, and simply exercise our ability to fork the good things they have given us and graft on the goodness that we want.
I am probably an atypical user, but I switched to KDE4 and like it.
For a long time I was on Gnome, but I don't actually like the task bar. Eventually I rolled my own working with Docky and Compiz. This was a pretty good solution because Compiz has some great features which I don't think get used enough (For example, making overlapping windows translucent when the focus changes, or the ability to zoom in on a window and have the zoom change when you change focus). I liked Docky too, probably for the same reasons that Mac users like their dock (it seems pretty similar, although I've never really used a Mac). But the latest version of Ubuntu brought with it a host of bugs in Compiz which meant that the features I liked stopped working. I tried Unity for a good 2 months, but it is really broken -- especially if you use focus follow mouse like I do. So I switched to KDE4.
KDE4 took some getting used to. But I really like plasmoids. Why do I need a task bar??? I'll just put whatever tool I want, wherever I want. I like the fact that I can resize them to any size I want (as you might have guessed from the zoom feature that I like, my vision isn't the greatest). I like Activities too. I spread out all my windows wherever I want them to be and use keyboard combos to get to the right desktop. I work primarily from a laptop that I carry around with me everywhere, so it's nice to have different contexts for each place. I can also pin up apps to show up in multiple activities.
If I were to complain, configuration in KDE4 is terrible. You *have* to configure it out of the box, because it is basically unusable the way it is, but it is really, really difficult to figure out where everything is. A complete reorganisation of the configuration would go a long way to helping KDE. Also, there are lots of things that just don't work except in the context that the developer imagined. I want a Systray plasmoid on my desktop. It doesn't work as far as I can tell. I have to put it in a task bar. OK. So I make a tiny task bar, put the systray in it and Bob's your Uncle. But it's sloppy.
Anyway, KDE4 isn't perfect, but I can (eventually) configure it to be very nice. I still like my minimalist Docky+Compiz (oh, and Stalonetray for those ridiculous gnome apps that insist on using the systray), but KDE4 is slightly better now that Compiz is broken.
I wonder if anybody on Easter Island ever said, "Hey guys. Do you think we might be running out of trees?" But you know, after the fact I'm sure they were all like, "Oh man. Yeah, you were right. Now that we're all dead I can see that putting up idols for the gods was not as effective as managing our forests would have been."
The funny thing is that Japan was heading in the same direction. By the beginning of the Edo period, the people there were at very high risk due to deforestation. A general ban on logging was put in place and it literally saved Japan from destruction.
If you bother to look, there is quite a large list of civilisations that have wiped themselves out due to exhausting their resources and degrading their environment. The list of civilisations which understood their predicament and did something in time to save themselves is pathetically small.
If you are already working for a company under contract, and they have no means to terminate the contract other than firing you, you often have a lot of leverage. One of my former employers tried to change my contract underneath me. I flatly told them that I was already under contract and that I was generally happy with the contract. None of the conditions for termination of the contract had occurred, so unless they wanted to negotiate with me I would stick with the contract I already had. At that point they told me it was a requirement of my job to sign the new contract. I looked their lawyer directly in the eye and asked, "Are you telling me that if I don't sign the contract, you're going to fire me?" So he's stuck between coercion and improper dismissal and he knows that I'm going to make life hell for him if he continues. So they gave up.
The thing that always gets me with these stupid things is that the best programmers are obsessive, details oriented people. Especially when I've worked at large companies we lost so many potentially good people because they wouldn't agree to the ridiculous terms that HR cooked up in the contracts. If you're serious about hiring the best, you've got to realise that those people are in demand and offer them better terms than the competition. For the best programmers, contract details are important.
Africa isn't just one of the poorest areas of the world, the continent is also the world's largest food importer
Africa imports food because they are poor. They are forced by the world bank and the WTO to accept agreements to buy grain from countries like Canada in exchange for loans. Many countries have become dependent not only on the loans, but also on the grain because spending a certain amount of money on buying grain was part of the loan deal. With cheap western grain, the local farmers are kicked out of the market. After a few years, there are no more farmers.
The international price of wheat was at $4 a bushel for as long as I can remember (and given that I'm quoting in $/bushel, it might give you an idea how long that is). There is no doubt that biofuels have increased that price (with some studies attributing all of the price increases to biofuels -- I'm not convinced myself, but I'm not an expert). Regardless, the price of wheat at the moment is hovering around $13 a bushel (if I've done my math correctly and a bushel of wheat weighs very close to 25kg). So it's gone up a huge amount.
But the problem is much more complex than you portray it. Western policies on farm subsidies have always kept the price of wheat (and other grains) at ridiculously low prices. $13 a bushel is actually *good* for African farmers because it means they can finally grow grain and make a profit... Except that they aren't allowed to, or the infrastructure has been destroyed, or the economy is shattered and they are currently dealing with hyperinflation, etc. The argument saying that high grain prices hurt Africa, is the same argument that wants Africa to be under the thumb of the west forever. Africa can feed itself. It doesn't need to buy grain if it fixes it's political problems and if the west stops trying to economically enslave them.
As an aside, the same trick was played on the Japanese (the WTO ordered Japan to buy rice from the US every year). But the Japanese, having suffered a huge famine after WWII as a result of US blockades during the war have a law making it illegal to sell anything but domestic rice (well, there are some exceptions, but not worth quibiling over). The result is that the Japanese dump all of the rice that they import. Last year, when there was a rice shortage in south east asia, they finally got permission to sell some of that rice, but usually they can't.
I don't disagree with you on the stupidity of burning food in get energy (although not all biofuels are food). But at the moment, this is by far the least of our worries in the unbelievably stupid arena of international food policy.
Likely considering a monopoly position. If you hold a large number of the key patents to a technology, you can effectively shut down all your competition. As bizarre as it sounds, my guess is that buying a monopoly position through buying key patents may be considered unfair competition.
There aren't any salesmen out there selling FOSS, and no slick ads for it on the teevee, so they'll never even know they had alternatives.
While this isn't exactly true (Novel certainly had salesman who were selling FOSS because I met one, and IBM certainly does as well), I often think that there's a huge hole in the software market. We've got companies like MS and Adobe who sell solutions to businesses, but what about pure system integrators piecing together FOSS and selling solutions to those same businesses? This is essentially the position the Cygnus put itself in with embedded development tools (and I suspect that Red Hat continues to do this now, but I haven't actually looked into it lately).
The biggest problem I see with FOSS vendors is that they can't seem to change their business models to match FOSS. Companies like Novel and Sun went about things ass-backwards by building free software that they thought people might like (or really, did whatever the hell they felt like) and then tried to sell it after the fact. You don't see a lot of companies integrating FOSS software to give them 90% of a customer's solution and then custom building the last 10%. The thing about FOSS is that because you can't control distribution, you have to get paid *before* you write the code. If you write the code first and offer no custom development support, why would anyone want to pay you? They'll just get it from one of your other customers for free.
I keep thinking about Michael Tiemann's description of how they started Cygnus and I think that his description of how important sales was to them is crucial. You've got to call up companies and tell them, "I've got the best solution for you because I'm not selling you software. I'm giving it to you. Instead, I'm selling the service of making the software work they way you need it to. And because I'm leveraging off free software, that service is going to be cheaper than the licenses for an uncustomized off the shelf solution." Somehow, I keep expecting companies to start doing this and making a lot of money at it, but it hasn't seemed to happened. I still don't quite understand why.
and people wonder why Somalians don't have enough money to buy food
Food distribution problems in Somalia has nothing to do with world food prices (which, even with biofuels is below production cost in many countries -- but that's another rant). The problems in Somalia are related to the Somalian civil war. To quote Wikipedia:
The civil war disrupted agriculture and food distribution in southern Somalia. The basis of most of the conflicts was clan allegiances and competition for resources between the warring clans. James Bishop, the United States last ambassador to Somalia, explained that there is "competition for water, pasturage, and... cattle. It is a competition that used to be fought out with arrows and sabers... Now it is fought out with AK-47s."[80] The resulting famine (about 300,000 dead) caused the United Nations Security Council in 1992 to authorise the limited peacekeeping operation United Nations Operation in Somalia I (UNOSOM I).[81] UNOSOM's use of force was limited to self-defense and, although originally welcomed by both sides,[82] it was soon disregarded by the warring factions.
Currently there is no world shortage of food. But there are areas of the world where food production and distribution have all but ceased due to political problems. There are also places in the world where virtually their entire GDP is going to pay off debt for food that they buy from the west while agreements with the WTO and World Bank disallow them from rebuilding their own agriculture infrastructure (as a precondition for the loan to buy food in the first place). Oh wait, I wasn't going to rant about that... sigh...
It would be fantastic if we could blame world hunger on biofuels, but it is not the case, unfortunately. Currently world hunger is a direct result of us being shitty to each other. This is not to say that it won't play a part in the future, though.
Slashdot Mirror
According to this article: http://www.e-ink-info.com/fujitsu-shows-new-prototype-color-e-reader Fujitsu is building something based on this and it has a refresh rate of 0.7 seconds. So pretty slow. Other articles ( http://www.e-ink-info.com/auos-sipix-e-paper-now-fast-enough-video-6fps ) suggest that some monochrome panels are capable of 6 frames per second and speculate ( http://www.e-ink-info.com/e-ink-do-not-expect-new-monochrome-e-ink-display-2011 ) that 24 frames per second may be possible in a matter of years.
So... it's still mostly useful for static displays, but in a couple of years we may be seeing it branching out into other applications.
Get your employer to sign them (or whoever you need to talk to). That's the way PGP was designed to operate (and I'm sure there are still PGP signing parties going on these days). Do a face to face with them, and give them the key via USB or whatever. They sign them on their machine. Then they know the stuff is from you (much, much, much better than a CA).
The sucky part of that is that's who I get my email pgp keys from. But really there needs to be a tiered CA system, where a CA is providing certs to anyone that asks, to people that have to prove themselves, and to government and other trusted sources. The way things are now, pulling the plug on an entire CA is the nuclear option.
Why do you need to get your email pgp keys from *anybody* except yourself? There are very few transactions where someone needs to know your actual identity. Most of the time, they need to know that you are the same person they talked to last time. Meet someone online (or even IRL) and exchange keys. Now when you receive email from that person you know that it is the person you talked to previously (as long as the key exchange is not compromised). Who cares what your real name is, or where you live, etc, etc.
Even (especially?) transactions with companies don't need a CA. Does a customer *really* need to prove who they are? Or do they just need to prove that they are associated with past interactions with the company? In fact, giving more information is an invasion of privacy. Why does Amazon.com need to know my real name to sell me a book? They just need my address and some way to receive payment.
Even the other way around is not particularly useful. What do I really know about Amazon.com? Nothing except that they sell books. My friend says that he buys books on Amazon.com all the time with no problem. So what I really want to do is make sure that the site that I'm going to is the same site that my friend went to. I need my *friend* to authorise the certificate. Because who am I going to trust? My friend or some CA that I've never even heard of before?
If I go to a site that I don't know about, then the certificate is worthless. Who cares if the CA knows *who* they are. It doesn't tell me anything about how they do business. It might me slightly useful for the situation where I have generally heard about a company, but don't have a key/certificate. But in this case, I still have to trust a CA that I know nothing about.
CAs aren't particularly useful for people like me and you. What they are *really* useful for is controlling who can do what on the internet. If I don't get a signed certificate, then browsers will jump up and down screaming that I might be an evil website. That's all. It's simply a sticker that you buy saying "This is a legitimate site". Do not want.
While there isn't a lot of research on the topic, what there is seems to indicate that open source software and "commercial" (i.e. not open source) software have similar defect densities. Here's a paper on the topic:
http://www.reasoning.com/pdf/MySQL_White_Paper.pdf
I've worked on both "commercial" projects and opens source projects. My personal experience has been that willingness to fix bugs is much higher on the open source teams. Usually the authors actually use the product in their everyday life and bugs affect them personally. They are highly motivated to fix them. On "commercial" software projects, my experience is that the authors of the software rarely use it in their every day life. Selection of bugs to fix usually comes from a project manager.
Both open source and "commercial" projects usually have large backlogs of bugs that never get fixed. The difference is that open source projects usually fix bugs that directly affect the authors, while "commercial" projects fix bugs that directly affect customers who have bought enough units to gain the right to complain (i.e. thousands of copies). However, with an open source project, if the authors decide not to fix a bug you usually have a number of options. You can complain on the developer's mailing list and plead your case. If that doesn't work, you can fix the bug yourself, or hire someone else to do it. With "commercial" software once you file your bug you usually don't even know if they will decide to fix it. You usually don't even know if it was fixed in the next version without buying it and trying it for yourself. If the program manager decides not to fix your bug, you have no recourse at all unless you have already bought thousands of copies of the software and can threaten not to upgrade to the next version unless they fix your bug. Even then they might decide not to.
"Well that's the thing with volunteer made software isn't it?" is what you wrote. Yes. That's the thing with volunteer made software. You have direct access to the developers to report your bug. You get informed whether your bug when your bug is being looked at. You can make a case for having your bug fixed. And if that doesn't work, you can fix it yourself. What is there that needs fixing again?
There is some truth to what you say, but I think you may be overestimating the population density of Asia. For example, I live in Japan and the other day a nice salesman from NTT (the state run telephone company) showed up to tell me that fibre was available in my town. For less than 5000 yen per month (about $60?) I can get a 200 Meg connection. I live in a small farming town with a population of about 25K. My prefecture (Shizuoka) has a total population of 3.7 million and a population density of 485 people per square km. The largest city in my prefecture has only 800,000 people. The terrain is mostly mountainous and we have regular earthquakes greater than 6.0 in magnitude. To top it off we also have several typhoons every year.
In contrast New York state has a population of over 19 million and a population density of 408 people per square km. Its largest city has more than 8 million people and has a population density higher than that of Tokyo. The terrain is similar to that of where I'm living, but there are rarely any large earthquakes and hurricanes mostly blow themselves out before they get that far north.
The thing is, I have no bandwidth caps and if I am to believe the nice salesman's charts, they actually have enough bandwidth to supply the connection they are giving me (i.e., they *aren't* over subscribed). I've had 3G on my Android phone for the last year as well and tethered to my laptop I can always get 400K download rates on FTP. And like I say, the only thing around here is surfers, and tea farms.
I don't doubt that trying to hook up all of America is going to be way more expensive than hooking up all of Japan. But there really is no excuse not to have decent service in at least *some* places in the US.
Patents lock small developers out of the market. "Defensive" patents only help corporations that have lots of them. If a company says "We'll sue you over infringement of these 100 patents", the defence of "Well, you're infringing on this one patent" isn't going to be effective. Because Apple, IBM, MS, etc have a lot of patents they effectively have a stand off between them. But they are afraid of upcoming companies that come out of nowhere to take part of their market. Patents stop that because there is no way for a small company to get their hands on tens of thousands of patents. While patent trolls hurt the big companies, they absolutely destroy small companies who get targeted by them. Thus, the big companies are willing to put up with the relatively predictable legal cost in order to avoid unpredictable competition in the marketplace.
CEO/PHB voice here
How does refactoring bring shareholder value? How does it boast the company's stock price? How does it increase revenue? .../CEO/PHB voice
By slowing down slightly and refactoring after each change, I increase the overall throughput of the development. Without the refactoring, the change comes back as quickly as possible, but over time, I get slower and slower. With refactoring, my ability to make changes is initially slower, but my rate is constant. There are two main benefits for refactoring from a shareholder value. The first is that long-term I can get more done. However, this is vastly overshadowed by the fact that with a well factored code base, my actions are more predictable. We can plan much more effectively, because my development rate is more regular. This means that sales and marketing get longer lead times and we have less surprises towards the end of the development cycle. We are able to set customer expectation a lot better because we have a very good idea of what we will deliver and when it will be delivered. R&D is less than 10% of expenditures in the average established software company. Sales is usually more than 30%. We need to do everything we can to make sales more effective, since this is where our money is being spent. Regular refactoring directly supports that action.
Or at least, that's what I've said in the past. I never have trouble making it fly.
That's why you shouldn't refactor that way. Predicting the future is hard, and even those people who think they are good at it, often aren't. It becomes a manifest destiny where they bend the new work to fit their old "brilliant" model -- in essence forgoing the refactoring in order to stroke their own ego. Refactoring should be a recurring event and developers need to understand that there is no overarching "best" design going into the future. You should refactor such that the software, as it stands now, is as simple as you can make it. When you add new code in the future, you then refactor again, to make it such that it is as simple as you can make it. Because you are refactoring constantly, the changes are usually small. Sometimes they are large, but because the code is as simple as it can possibly be, the changes are not difficult to make.
Trying to design for the future increases complexity of the software and impedes your ability to refactor, As I mentioned, you may be unwilling to give up your brilliant first design. But also, changes you expect down the road may not (probably won't) happen exactly the way you envisioned them. As you refactor to meet new requirements, you end up shifting a lot of code that doesn't even do anything, because it is only required in the (unspecified) future. This becomes a large source of errors, since your refactorings are hard to test. Usually there are complaints that the refactoring "broke" the design and that refactoring should be limited to avoid "code churn".
In order to explain the necessity of refactoring to managers, I usually explain that in development there is a tradeoff between interactivity and throughput. If you want any specific activity to finish as quickly as possible, then there is a cost to pay. That cost is throughput. My change is as fast as possible, but tomorrow I'll slow down a bit. The next day a bit more, etc. Over time, my "as fast as possible" isn't very fast any more. Instead, I try to optimise throughput on the team. I want the overall development effort to be as fast as possible. But there is a cost for that. It means that each individual change is not as fast as possible. However, the rate of changes is constant over the project (actually, it is usually slightly increasing since clean code gives some reuse opportunity -- not as much as many people think, but enough to slowly accelerate the project). Over the period of a year the throughput is higher. This is usually desired by managers (but not always -- for one-off projects, it is sometimes better to optimise for interactivity over throughput).
Another very important part about refactoring is to make it a required part of each change. Changes aren't finished when the functionality is acquired. The changes are only finished when the affected code has been refactored to make the design as simple as possible for the current functionality. There is never a line item on the todo list that says, "refactor X". Similarly, bad code that isn't used directly, or modified is never touched. We don't improve code for the sake of improvement (as refreshing as it would be). Instead you only refactor code that is directly related to your changes. In legacy systems this is difficult because you often get the "pulling a loose thread" situation; you start refactoring and quickly find that you are touching everything in the system. Usually it's a good idea to grab a couple of people and discuss the best place to limit your changes.
The result of doing work this way is to make it so that the manager never has input on whether you refactor or not. It is a technical, not strategic decision and belongs in the hands of the developer. If your manager understands that your goals are the highest possible throughput, and your manager trusts your technical decisions, then there is no problem. If this situation doesn't exist, you need to have a talk with your manager (or possibly change jobs since a manager who doesn't trust you will have no ability to manage you properly).
I think it's useful to look back at TFA. The point he was making was that R and D are 2 different things. To be fair, Microsoft is one of the few companies that actually invest in research (R), but in every software company that I'm aware of the D (development) dramatically dwarfs the R. One of the things most frustrating about software patents is that they are usually the result of refinement (if that!) of existing techniques where no real novel thought has gone into it. One could look at a company like MS and say that their high R&D costs are a result of inefficiencies in their development efforts as much as they are the result of trying to do something new (and I say that with the full realisation that MS is better than almost any software company with regard to research). Likewise, while Google also does a lot of research (comparatively), I get the impression that their R&D numbers are high mostly because they pay a lot for their developers. It doesn't necessarily follow that basic research will be done.
Now what the Libre Office guys need to do is wander up to them and say, "You're saving 40 million Kroner in licensing fees. But is there anything in LO that doesn't meet your standards? Because for a tiny fraction of those savings we'd be happy to fix the problem right away."
These used to be commonly accepted ideas before we gutted public education and Fox News began blaring propaganda 24/7.
I agree with your general principle, but I don't think you have thought this part through. If you think back, there will be a time in your life where society changed. When you were young, people followed ideals, not fear; politicians did what they believed was right, not what their donors told them to do; law enforcement worked to keep people free, not to control them. When did society change? It changed when your perception changed and it is only actually your awareness that has changed.
Not much of actual substance has changed in our lifetimes. When I was a kid (most likely a fair amount of time before you were a kid), I used to laugh at the one sided, blantant propaganda machine that was American news. I only stopped laughing when I realised that my own country's news was just as bad (just different propaganda). I laughed at the unbelievable ignorance of Americans apparently educated simply to be god fearing, flag worshipping sheep until I graduated high school and as a long time resident of Manitoba didn't know who Louis Riel was.
The problem with thinking that the world has changed is that you will focus on the wrong things. You will waste your energy railing against something that, while being a strong symptom of the problem, is not the problem itself. Instead of looking at what has changed, and trying to find what has spoiled, rather look for things that haven't changed. Look for things that were rotten from the beginning. This will give you a much better insight into the issue, IMHO.
About 5 years ago I ditched my car and replaced it with a bicycle. What hit me pretty quickly (especially since I wasn't in great shape) was that I didn't want to ride around for hours on end finding things. In a car, if you make a mistake or simply want to try a new route somewhere, going an extra couple of km is nothing. On the bike it was frustrating, tiring and at the end of it I was always worried if I would remember how to get home again (without adding an extra 5 km to my trip). The GPS made a huge difference to me and enabled me to get a better handle on if the distance was too far, etc, etc. I remember always jumping through hoops to take buses to the train station and one day I punched it into the GPS and realised that it was only 20K. After that I never took the bus again.
On the down side, the GPS always gives me the shortest route to my goal. As I live near mountains, this translates to always giving me the steepest route to my goal. It took me a while to jam that into my head. It would be nice if the GPS had a feature to avoid gradients of over 7% or so...
We haven't been overwhelmingly defensive in about a decade now.
I hate to break it to you, but the US hasn't been overly defensive for a lot longer than a decade. Korea, Cuba, the Dominican Republic, Vietnam, Grenada, Panama, Persian Gulf, Bosnia and Herzegovina. At least Korea and Bosnia and Herzegovina were part of a larger effort, so I suppose we can give a few brownie points. Of course these are only direct military interventions from 1950 to 2000 and don't include the dozens of countries where the US has funded uprisings, overthow of the government, etc, etc. Hell, the US pays Pakistan with weapons to allow it to bomb Pakistani cities in hopes of killing terrorists. These weapons are used to continue Pakistan's war with India. Things like this just make my head spin.
It appears from my perspective that US foreign defensive policy is to get actively stuck in and compel other nations to follow it's world view, using force if necessary. It is not the only country in the world to be doing this, but as the most powerful nation in the world (economically and militarily) I personally feel that its international reputation of being a bully is well deserved. That the US population feels comfortable with the idea of the US as the "police of the world" is truly frightening for a lot of non-Americans.
I've only tried briefly, but I think Compiz works fine on KDE4.5/4.6. I think it might run faster in the situations you are talking about. I've noticed the speed of kwin is heavily dependent up on the theme you choose. On my ridiculously underpowered netbook (which I like using for some reason) it can be unusably slow with some themes, but reasonable with others. Compiz seems to have more consistent performance.
Actually, the US's debt to GDP ratio hasn't really changed all that much in the last 20 years. If you compare it to other first world countries, it's reasonably fine. Even though the debt keeps rising, the country keeps making more money, so the amount of debt per income is holding relatively steady (well, slight upward climb, but not astronomical).
I didn't read TFA, but here are some thoughts to consider. printf debugging is only useful if you have an uncomplicated subsystem. You have to be able to quickly find the area where the problem may lie. You have to be able to easily identify and set up the scenario that is causing the problem. You have to easily be able to modify the code, redeploy and run it. I find that a lot of people will say, "My system is too complex for that". What they don't quite grasp is that their system is broken.
If you need a debugger to evaluate the system when it enters a broken state, your software composition is likely the fault. You should be able to write a quick script that sets up the circumstance that you are interested in. If you have to actually run the entire software to get into this situation, they you likely have serious coupling issues that you should resolve.
The same is true for tracing. Generally tracing is useful when you can't understand the code path that led to it arriving at a particular location. This probably means that either your interfaces are confusing, or you have poor cohesion. You may have issues where functions are doing more than one task, or you have many poorly factored methods that copy and paste similar code.
For me one of the biggest incentives to use a debugger is because the build system is broken. I can't set up scenarios to test because it takes an hour to build and deploy the system. Again, this could be due to coupling/cohesion problems in the software composition, but it is often just laziness when creating the build system. Having a continuous integration/build system is extremely helpful.
When you are working with a legacy system, sometimes there isn't much you can do. The pooch was screwed years ago and apart from rewriting the whole damn thing, you just aren't going to get there from here. The problem comes when the programmers don't even realise the inherent problems in their system. They have 2 million lines of horribly organised libraries and code copy and pasted all over the place. They have 200 line long (or more!) methods that duplicate functionality from a hundred other 200 line long methods. The debugger lets them do this and stay sane.
Taking away the debugger and telling them to use printfs (with no tracing subsystem!) shows them the hell that they have created. Of course, even then they often don't take the hint...
There aren't good engineering practices in software. This is why I abjectly refuse to call myself an engineer (that and I'm *not* an engineer). Can you tell me with a known degree of certainty the probability that a software component will fail? What procedures would you put into place to give you that number (keeping in mind the halting problem)? What procedures would you put into place to mitigate those failures? Because I'm drawing a big gigantic blank here.
Look, I'm all for using "Software Engineering" practices. Personally, in my career I have championed TDD, peer review, acceptance tests written in advance by someone other than the programmers, etc, etc, etc. But this isn't engineering. The best I can tell anyone is, "Hey, it doesn't break on *my* machine. Yeah, I think the probability of it breaking on your machine is 'low'. No, I wouldn't like to specify a number, thank you very much." Why do you think software never comes with a warrantee?
I often wonder what we could do to actually make this an engineering discipline. For one thing, I think we really need to invest in developing stochastic testing techniques. We need to be able to characterise all the inputs a program can take and to test them automatically in a variety of different ways. But this is the stuff of research. There are some things we can do now, but it's all fairly naiscent technology. Maybe in 20 years... :-P
Not that I disagree with you, but to play devil's advocate, where are the developers that disagree with this direction? If we're really so keen to keep what we've got, why aren't we forking? There are a lot of developers working on Gnome/KDE/etc, and they are all power users. Why are they building systems that they should hate? What's going on?
In my opinion, the problem is that *all* of the desktop environments suck. I mean, I think I started with TWM and I liked it at the time, but I would never go back to it now. I transitioned through a lot of different window managers and desktop environments and there isn't one that I think, "Yeah, that was pretty much right". Obviously if I did, I'd just switch back to it. The problem is that these new ideas generally *are* better than the old ideas, but that they are throwing out the baby with the bath water. For example, focus follows mouse has a vastly better workflow (IMHO) that click to focus. Why is it getting left behind? It's because people aren't used to it. Eventually, even I might give it up if they give me enough in exchange. But I'll go kicking and screaming all the way.
What we really need to do is to stop complaining about what is being taken away from us, and simply exercise our ability to fork the good things they have given us and graft on the goodness that we want.
Yeah, I'm too lazy to do it too...
I am probably an atypical user, but I switched to KDE4 and like it.
For a long time I was on Gnome, but I don't actually like the task bar. Eventually I rolled my own working with Docky and Compiz. This was a pretty good solution because Compiz has some great features which I don't think get used enough (For example, making overlapping windows translucent when the focus changes, or the ability to zoom in on a window and have the zoom change when you change focus). I liked Docky too, probably for the same reasons that Mac users like their dock (it seems pretty similar, although I've never really used a Mac). But the latest version of Ubuntu brought with it a host of bugs in Compiz which meant that the features I liked stopped working. I tried Unity for a good 2 months, but it is really broken -- especially if you use focus follow mouse like I do. So I switched to KDE4.
KDE4 took some getting used to. But I really like plasmoids. Why do I need a task bar??? I'll just put whatever tool I want, wherever I want. I like the fact that I can resize them to any size I want (as you might have guessed from the zoom feature that I like, my vision isn't the greatest). I like Activities too. I spread out all my windows wherever I want them to be and use keyboard combos to get to the right desktop. I work primarily from a laptop that I carry around with me everywhere, so it's nice to have different contexts for each place. I can also pin up apps to show up in multiple activities.
If I were to complain, configuration in KDE4 is terrible. You *have* to configure it out of the box, because it is basically unusable the way it is, but it is really, really difficult to figure out where everything is. A complete reorganisation of the configuration would go a long way to helping KDE. Also, there are lots of things that just don't work except in the context that the developer imagined. I want a Systray plasmoid on my desktop. It doesn't work as far as I can tell. I have to put it in a task bar. OK. So I make a tiny task bar, put the systray in it and Bob's your Uncle. But it's sloppy.
Anyway, KDE4 isn't perfect, but I can (eventually) configure it to be very nice. I still like my minimalist Docky+Compiz (oh, and Stalonetray for those ridiculous gnome apps that insist on using the systray), but KDE4 is slightly better now that Compiz is broken.
I wonder if anybody on Easter Island ever said, "Hey guys. Do you think we might be running out of trees?" But you know, after the fact I'm sure they were all like, "Oh man. Yeah, you were right. Now that we're all dead I can see that putting up idols for the gods was not as effective as managing our forests would have been."
The funny thing is that Japan was heading in the same direction. By the beginning of the Edo period, the people there were at very high risk due to deforestation. A general ban on logging was put in place and it literally saved Japan from destruction.
If you bother to look, there is quite a large list of civilisations that have wiped themselves out due to exhausting their resources and degrading their environment. The list of civilisations which understood their predicament and did something in time to save themselves is pathetically small.
I often wonder what list we'll be on.
If you are already working for a company under contract, and they have no means to terminate the contract other than firing you, you often have a lot of leverage. One of my former employers tried to change my contract underneath me. I flatly told them that I was already under contract and that I was generally happy with the contract. None of the conditions for termination of the contract had occurred, so unless they wanted to negotiate with me I would stick with the contract I already had. At that point they told me it was a requirement of my job to sign the new contract. I looked their lawyer directly in the eye and asked, "Are you telling me that if I don't sign the contract, you're going to fire me?" So he's stuck between coercion and improper dismissal and he knows that I'm going to make life hell for him if he continues. So they gave up.
The thing that always gets me with these stupid things is that the best programmers are obsessive, details oriented people. Especially when I've worked at large companies we lost so many potentially good people because they wouldn't agree to the ridiculous terms that HR cooked up in the contracts. If you're serious about hiring the best, you've got to realise that those people are in demand and offer them better terms than the competition. For the best programmers, contract details are important.
Africa isn't just one of the poorest areas of the world, the continent is also the world's largest food importer
Africa imports food because they are poor. They are forced by the world bank and the WTO to accept agreements to buy grain from countries like Canada in exchange for loans. Many countries have become dependent not only on the loans, but also on the grain because spending a certain amount of money on buying grain was part of the loan deal. With cheap western grain, the local farmers are kicked out of the market. After a few years, there are no more farmers.
The international price of wheat was at $4 a bushel for as long as I can remember (and given that I'm quoting in $/bushel, it might give you an idea how long that is). There is no doubt that biofuels have increased that price (with some studies attributing all of the price increases to biofuels -- I'm not convinced myself, but I'm not an expert). Regardless, the price of wheat at the moment is hovering around $13 a bushel (if I've done my math correctly and a bushel of wheat weighs very close to 25kg). So it's gone up a huge amount.
But the problem is much more complex than you portray it. Western policies on farm subsidies have always kept the price of wheat (and other grains) at ridiculously low prices. $13 a bushel is actually *good* for African farmers because it means they can finally grow grain and make a profit... Except that they aren't allowed to, or the infrastructure has been destroyed, or the economy is shattered and they are currently dealing with hyperinflation, etc. The argument saying that high grain prices hurt Africa, is the same argument that wants Africa to be under the thumb of the west forever. Africa can feed itself. It doesn't need to buy grain if it fixes it's political problems and if the west stops trying to economically enslave them.
As an aside, the same trick was played on the Japanese (the WTO ordered Japan to buy rice from the US every year). But the Japanese, having suffered a huge famine after WWII as a result of US blockades during the war have a law making it illegal to sell anything but domestic rice (well, there are some exceptions, but not worth quibiling over). The result is that the Japanese dump all of the rice that they import. Last year, when there was a rice shortage in south east asia, they finally got permission to sell some of that rice, but usually they can't.
I don't disagree with you on the stupidity of burning food in get energy (although not all biofuels are food). But at the moment, this is by far the least of our worries in the unbelievably stupid arena of international food policy.
Likely considering a monopoly position. If you hold a large number of the key patents to a technology, you can effectively shut down all your competition. As bizarre as it sounds, my guess is that buying a monopoly position through buying key patents may be considered unfair competition.
There aren't any salesmen out there selling FOSS, and no slick ads for it on the teevee, so they'll never even know they had alternatives.
While this isn't exactly true (Novel certainly had salesman who were selling FOSS because I met one, and IBM certainly does as well), I often think that there's a huge hole in the software market. We've got companies like MS and Adobe who sell solutions to businesses, but what about pure system integrators piecing together FOSS and selling solutions to those same businesses? This is essentially the position the Cygnus put itself in with embedded development tools (and I suspect that Red Hat continues to do this now, but I haven't actually looked into it lately).
The biggest problem I see with FOSS vendors is that they can't seem to change their business models to match FOSS. Companies like Novel and Sun went about things ass-backwards by building free software that they thought people might like (or really, did whatever the hell they felt like) and then tried to sell it after the fact. You don't see a lot of companies integrating FOSS software to give them 90% of a customer's solution and then custom building the last 10%. The thing about FOSS is that because you can't control distribution, you have to get paid *before* you write the code. If you write the code first and offer no custom development support, why would anyone want to pay you? They'll just get it from one of your other customers for free.
I keep thinking about Michael Tiemann's description of how they started Cygnus and I think that his description of how important sales was to them is crucial. You've got to call up companies and tell them, "I've got the best solution for you because I'm not selling you software. I'm giving it to you. Instead, I'm selling the service of making the software work they way you need it to. And because I'm leveraging off free software, that service is going to be cheaper than the licenses for an uncustomized off the shelf solution." Somehow, I keep expecting companies to start doing this and making a lot of money at it, but it hasn't seemed to happened. I still don't quite understand why.
and people wonder why Somalians don't have enough money to buy food
Food distribution problems in Somalia has nothing to do with world food prices (which, even with biofuels is below production cost in many countries -- but that's another rant). The problems in Somalia are related to the Somalian civil war. To quote Wikipedia:
The civil war disrupted agriculture and food distribution in southern Somalia. The basis of most of the conflicts was clan allegiances and competition for resources between the warring clans. James Bishop, the United States last ambassador to Somalia, explained that there is "competition for water, pasturage, and... cattle. It is a competition that used to be fought out with arrows and sabers... Now it is fought out with AK-47s."[80] The resulting famine (about 300,000 dead) caused the United Nations Security Council in 1992 to authorise the limited peacekeeping operation United Nations Operation in Somalia I (UNOSOM I).[81] UNOSOM's use of force was limited to self-defense and, although originally welcomed by both sides,[82] it was soon disregarded by the warring factions.
Currently there is no world shortage of food. But there are areas of the world where food production and distribution have all but ceased due to political problems. There are also places in the world where virtually their entire GDP is going to pay off debt for food that they buy from the west while agreements with the WTO and World Bank disallow them from rebuilding their own agriculture infrastructure (as a precondition for the loan to buy food in the first place). Oh wait, I wasn't going to rant about that... sigh...
It would be fantastic if we could blame world hunger on biofuels, but it is not the case, unfortunately. Currently world hunger is a direct result of us being shitty to each other. This is not to say that it won't play a part in the future, though.