Just because Minux has only 100 lines of assembly doesn't mean anything about Darwin, even if Darwin has microkernel components, so your association there is a bit fallacious. Unless it's changed recently, Darwin does have microkernel (mach in fact) underpinnings, but a complete FreeBSD subsystem is grafted onto that. So if anything Darwin is a hybrid kernel. Like most real systems out there, it's not a complete microkernel system.

As far as industries go, farming is in a rather unique situation. Manufacturing and processing plants, which can use a fair amount of water, simply pass on their increased costs to the consumer. Water conservation increases somewhat, which is good, while overall prices go up. Farmers, on the other hand, cannot pass on their costs to consumers. They are price takers. So simply making farmers pay more for water may help somewhat, but ultimately it will just drive farmers out of business. If enough farmers are driven out of business and production plummets (a likely scenario), supply will dwindle and prices will go up, which benefits the farmers who help on by the skin of their teeth. But overall it's a huge negative to everyone.

It's unfortunately that urban and rural areas are beginning to clash over water. More and more urban populations are so far removed from food production that they don't realize that cutting off farmers entirely is cutting off their own food supply, at least in part. CA is in a position where a lot of water is virtually exported in the form of exported foods, which is a problem (although a lot of food gets imported as well), but if consumers are willing to pay for it, farmers can and will switch to growing foods exclusively for local consumption.

Currently, as far as I can tell, most cities don't recycle water very much. They are dependent on a fresh source (hence the desalination plant), which goes through the city, and is then treated and released. There's very little technical reason why nearly 100% of the water that isn't lost to runoff or evaporation can't be recycled and put back into the potable supply. Surely if people are willing to shut farmers down they should be willing to recycle their own waste water, including sewer water. Maybe only 25-30% of water can be recycled, but that'd be a good help.

Bombing is going so well for us isn't it. And the invasion of Iraq and Afghanistan with guns and bombs and prisons and such worked amazingly well. Just like these FBI stings work so well. Sure ISIS is slowly crumbling under the constant assault, and will likely be defeated soon. But when it's over the people who are left will be in more need than ever before, and even more vulnerable. ISIS2 will be even worse. In short it's just not working for anyone involved.

Look, at some point we will have to engage on an ideological level. We must find out why so many people are susceptible to fanatical messages and figure out how to convince them that the moderate way is better for everyone. If everyone did have adequate access to mental health care (to say nothing of basic health care, food, and jobs), then yes, ISIS would have had no power to begin with. Comparatively the US doesn't have the problems with certain populations and extremism that other nations in the middle east have, because of the fact that basic needs are usually met.

Perhaps western ideology has little to offer these people. If so then both they and we are in serious trouble.

As long as something is still radioactive, there is wasted energy (not to mention dangerous to store) that could be extracted. That's what the IFR program was all about. Process the material until it breaks down into things with such a short half life that it doesn't make sense to process them anymore. And at that point you have waste that has a radioactive half life of decades not centuries or thousands of years. And it sounds like in the short decade they were in operation, they were very successful.

As the article stated, the end of the IFR program was an entirely political decision, not a technical one. Given that we need the technology so desperately from a humankind point of view, it bothers me that politicians today won't even discuss the idea. They are willing to entertain conventional, inefficient nuclear energy, at least to give it lip service.

The good news is that in the future when logic prevails, all the stores of toxic nuclear waste can be mined for fuel for the next generation of IFRs. Provided it can be stored safely.

Except if you study the IFR idea, you'll find there are very few rational concerns about it. In fact it handily addresses all the traditional concerns about Nuclear energy. Safety, waste, etc. If the article linked to by the GP is correct, even the worry about plutonium bomb making is unwarranted as IFR technology simply can't be used to make a bomb. If this scientist is correct (and I see no evidence he's not--after all he worked on this project for many years), then any politician opposing IFR is irrational, or in a conflict of interest with some aspect of the energy sector.

QB64 is only a download away and presents a classic QB4.5 style text ide with an integrated compiler and debugger. It's as close to an out of box learning environment as you can get. And it can do graphics in an SDL window. Might be a perfect start for some budding programmer. Just encourage structured programming and you should be fine.

In a different vein, installing Python and IDLE isn't hard and gets you running very quickly.

I haven't anything at that price point. I gave half a dozen their point to point devices and they rock. I get a full 100MBs over about 800 feet. I'm very happy with them. Hope this issue with the kernel source gets sorted out. They seem like a good little company and they have good affordable hardware.

A local wireless ISP in my area uses their equipment exclusively. Works very well.

You misunderstand. By verbosity I don't mean boiler plate, java-style. I mean simply that there are more keywords. If/Then/Else/End if, Do Loop, For/Next. Again no worse than Pascal which you don't have any problems with.

QtCreator is much closer to the RAD concept than you state here. Callbacks can be filled out in the IDE. It's not like you state in your post. However, the RAD concept isn't always super flexible, and modern GUI systems like Qt and GTK all let you work on the GUI in a programmatic way that is often much more powerful, but still easy and flexible. If you insist on your definition of RAD you'll likely run into limitations (any RAD system) and be disappointed. It's a good concept but in practice I think you need more than that. Except for certain vertical markets, I don't really see the point of full RAD to be honest. Especially when a half dozen lines of explicit code can do the same thing, but exactly how I want it. The XML gui design is far far better in my opinion. Load the ui file, autoconnect the callbacks to your code, done.

BASIC these days is little different from Pascal so I don't see why this is a downside. BASIC is every bit as modern as any other language and structurally equivalent to any modern static language. It's more verbose than C and similar languages, and maybe as verbose or slightly less verbose than Pascal is. Not sure about RealBASIC, but other BASIC dialects suffer from way too many things being a part of the language with custom syntax, rather than a callable function in the runtime. For example the Pset, Line, Circle, Draw functions. But really, any BASIC hate because its BASIC is about 30 years behind the times.

I don't understand why you couldn't get QtCreator working. Qt is easy to install and use on Ubuntu. And the Qt QUI designer is very easy to work with.

I would say that Python + libglade + glade is also a pretty good combination. It's not quite the RAD experience you seem to want, but it is a fast and powerful way of developing GUI apps, thanks go a nice API and Python.

I've read some good criticisms of systemd by another init system developer. He had valid things to say and put them on his blog in a nice point by point way that can be responded to and rebutted.

Rather than bad-mouthing Red Hat on slashdot, why not put up a direct, technical critique of systemd on your own web site (or post it here). I know many people would appreciate having a point by point critique. You say their code is a "mess" but what does that even mean? Please provide examples (such examples can only benefit everyone). Otherwise it's FUD. I know you probably feel like it's not worth your time, yet you post a half dozen or more anti-systemd posts here. So you clearly have the time.

Your mistake was going to Best Buy to find a cable. You're better off going to Princess Auto of all places to find cheap ethernet patch and HDMI cables. No hard drives though. And everything smells like smokey rubber.

Home Depot carries the best little set I've owned:

http://www.homedepot.com/p/Hus...

I have probably bought half a dozen of them as they are super handy. If you take out the little plastic insert in the handle, you can put all the bits in the handle also.

How do you know their code is dangerous? Have you reviewed it and published your results? Systemd is bloated? Have you even looked at the code? You do realize that systemd-init is not much bigger than sysv init was.

Furthermore, I don't think Red Hat would support systemd if their best engineers (and I know several of them; they are very smart people) doubted it. In fact if you read up on systemd you'll find that initially Red Hat was hesitant to pursue systemd. The systemd devs proved their case and won people on technical merit, especially as Linux has been moving into new areas like virtual machines and containers. And other distros are picking it up because it addresses major shortcomings that were starting to really impact Linux.

Interesting you should feel systemd is the worst of the lot when every commercial Unix out there abandoned sysv init years ago. Solaris, HPUX, Apple. You name it. They all did for the same reasons. init scripts are error-prone, clunky, hard to audit, and a maintenance nightmare. You couldn't even move an init script between systems. Have your worked with modern systems that employ containers, storage pools, logical volumes, hotplugged ethernet, storage, etc? I have, and it always was a bit kludgy before. Just consistent naming of ethernet devices is a nice benefit of systemd. Back in the dark days of Linux I would often put in ethernet cards from different manufacturers just to make sure I could map names to them in a consistent way.

Sorry, that's not udevil. That should be traditional udev, or eudev.

So far as I know, gvfs is dependent on udev, not systemd. There are versions of udev still available out there that are not part of the systemd. On systems running systemd, udev is going to be provided by systemd-udev.

So if you could rebuild your packages with a different udev implementation like udevil, gvfs could be build against it possibly.