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.

And it was a bad idea when OS X did it, and it's still a bad idea. I hope they can be disabled (this is actually a GTK thing, not a Gnome thing). I can see how this is useful on a very small screen with a finger as the pointer. But not a mouse on a desktop. We've really gone backwards in usability on computer desktops generally in the last 5 years. Perhaps this coincides with the rise of the "user experience" field of thought, rather than focusing on intuitive "user interfaces."

FUD FUD FUD. Systemd is not a hard requirement of Gnome. Gnome developers have chosen to focus on using systemd-logind at this moment, but there's no reason why ConsoleKit couldn't be updated and maintained for use on other platforms. Gnome developers with their finite resources have chosen not to work on ConsoleKit, but you certainly could.

From the Linux Voice interview:

Some people donâ(TM)t realise that when Gnome started making use of Logind, I actually wrote the patch for that. I ported GDM onto Logind. But when it did that, I was very careful to make sure it would still run on ConsoleKit. I didnâ(TM)t want to have those fights â" if people want to continue running ConsoleKit, they can. Those patches made it in, but some people saw that Gnome now works with Logind, hence it must not work with ConsoleKit any more!

But thatâ(TM)s actually not true. And to my knowledge the code is still in there â" the compatibility for ConsoleKit. The Gnome team has the general problem though, that nobodyâ(TM)s willing to maintain it. People who want to stick to the old stuff, they actually need to do some work on it. If they donâ(TM)t, then it will bit-rot and go away.

And just to be clear, logind is not some part of a bloated init system. It is a service that is developed and shipped with the systemd project but it is not part of init, and is a completely optional part of systemd.

I think you'll find you only get the $10.99 price the first time. after that it's typically more like $25 or more a year for a .com registration. At least it is on godaddy.

I would like to switch off of godaddy, but I only ever remember to think about it when it's time to renew, and from what I've been told, during this renewal time your name is locked and you can't migrate away. Not sure if this is just a godaddy cash grab, or if that's the way ICANN works in general. I use godaddy only for the name registration; I do all my own DNS and hosting.

Then why do you want bash or csh, which are inherently unix-centric and require the use of forward slashes, and know nothing about windows drive letters?

From your post there I can tell you've never used cygwin. It uses /cgydrive/c for C:, not /mount. Which isn't that hard to deal with. Works well for me, since I'm used to Unix to begin with.

There are a variety of command-line shells available for Windows you can try out. They each seem to somewhat resemble cmd.exe with various enhancements.

Don't you mean there are cheaper methods of heating than resistive heating? Because as far as I can tell, resistive heating is 100% efficient. Incandescents convert some fraction of the input energy to visible light. Almost all of the rest is emitted as heat. And if there was no light emitted, a resistive element is nearly 100% efficient. It's just that compared to cheap gas it's not particularly cheap to heat with electricity.

My computer is 100% efficient at converting every last drop of electricity that goes into its power supply to heat.

And I actually don't think the OP is really joking. In northern climates, moving away from incandescent lighting will mean that more heating from other sources is required. But even with additional heating needed, it is still going to cost you less in the end at least in terms energy cost, not counting investment cost.

Correct. Kerberos requires a reasonable synchronization of system clocks in order to work. Thus NFSv4 indirectly requires some form of time synchronization.

Doesn't look like he bothered with the synchros. And at the low input speeds his demonstration uses, they aren't necessary either. The dog clutches aren't spinning that fast so as to cause a lot of damage while engaging and they take no load in this demonstration.

And even on a real car transmissions, synchros are not actually necessary on real transmissions either; you just have to know the theory of how to shift.