Not replaced, you dummy.

Elevated to a new level.

Sorry, GP meant: the only fully hardware accelerated encryption method; implementation is approved by Intel Inc.

No, I will not be. I have used in the past the Borland Delphi for 5+ years and well aware of the limitations which come with the paradigm (rigid system libraries, "there is only true way to do it", "if there is no button for it, it's impossible", and so on). (And yes, to this day, I deeply hate Borland Delphi.)

I'm interested in RAD for specific purpose, so to say. To show that GUI development can be as easy as writing 10-20 lines of shell, but with the bonus of having a UI which is little bit more than text console. And, well, introduce some GUI into the Linux part of the product.

I do not look at them as a programming language or programming environment.

I see them as a tool to quickly develop and deploy a simple GUI, when the text console doesn't cut it.

Verbosity is the problem.

If I were fine with the screens and screens of the boilerplate code, I would have simply used the Java.

As I heard it was a systemic problem back then: not all package dependencies were declared, meaning that after installation you have to also install bunch of other stuff to make it working. (Many years ago, first time I tried QtCreator, it actually refused to run, because some linked libraries were missing.)

I'm not sure about now, but back then it wasn't even close to anything RAD. It was only a helper to create the GUI in a XML form, which was back then not even properly integrated with the rest: one had to write some code manually to actually tell Qt what resource corresponds to the window. And add resource manually to the resource file.

Yes, it is not RAD. And for that I already use QT + C++, which provides very powerful, simple and no-fuss API to build GUIs dynamically (without external UI building tools like glade or Qt Designer).

The problem is not me per se - I have no problems with most of the stuff. The problem are the other team-members who are not well versed as me in the scripting languages and building GUIs. On many past projects I have left behind lots of stuff which 95% of coworkers can't support or develop further. And I want to solve the problem by throwing in something that requires as least boilerplate as possible, stays as close to demos/examples as possible. I'm simply trying to find something to help the people start moving in the right direction.

Xubuntu 14.04 says that the installation would take 195MB of space. Bit heavy. Worst part: it is BASIC.

On the positive side, Lazarus + FP SDK, requires almost 1GB of space on my Xubuntu.

My ultimate goal is to be able to put together a quick UI, check in the source, and tell in few words to others who going to check it out how to compile it and get it running.

All in all, Xojo gets on the short list of things to try.

Only after I have pressed "Post" button, I hare realized that I probably given not enough context.

"Anything unique to a Linux developer who looks for RAD on Linux"?

From RAD for Linux, I'm aware only of the FreePascal-based Lazarus (Borland Delphi remake).

Past attempts with the KDevelop (and QtCreator) were pretty abysmal: right after "apt-get install" and few clicks to throw together UI, they were failing simply to compile the "Hello World" msgbox application. (And wild goose chase to install what was missing was counter the whole idea of *rapid* application development.)

Does Mono provide something unique to grant a look at it?

There is no such thing as generic Android phone.

That became patently obvious to me when I have tried to buy a "generic" ARM board (Raspberry, Banana, Odroid) for Ubuntu.

It just doesn't exist.

There is no IMB/Intel/Microsoft aliance to help create and maintain a standard ARM-based platform. And it seems all vendors try to differentiate, making the devices slightly incompatible with each other.

The most ridiculous part is that past boot loader/after kernel is loaded, differences are minimal and can be expressed with the Linux' device tree. But it is apparent that nobody makes an effort even to catalog the differences. Google, with their rolling releases and "selected" devices, is simply oblivious to the rest of the market.

None. Or rather: Linux desktop with systemd and Wayland is headed the way of mobile phones.

At least in the past, Samsung devices were recommended. They keep backup copy of the original OS on the flash, I was told. If you flash alternative OS and something goes wrong, you can still boot the original OS and repair/reinstall. (One of the reasons why CyanogenMod was originally developed on Samsung devices.) But I haven't tried that personally.

My FireFox on Ubuntu 14.04 routinely forgets the selected spellcheck language, and does not work until I select again the English (US).

So no, not PEBCAK. Just Mozilla doing their fine job as usual.

By the time it might/could happen, stealth tech would be mature enough. But all this buzzing noise outside...

P.S. Never, because drones do not solve any particular problem. Or: "Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway." (c)

Long time ago I have read about. The crater was known about for many years now. But for it to be registered officially as an impact crater, they had to find the impact center and let other scientists review the work. When I read about it, they found the suspected impact center and were preparing for drilling. From the TFA, it seems that they have finally dug up the evidence, but I see no mention of it being officially confirmed.

Crater wasn't found. They have just dug up and analyzed the first samples. No mention of it being "confirmed". Though Wikipedia still lists it as unconfirmed.

For more info see: (excluding the "unconfirmed structures") List of impact craters on Earth, Earth Impact DB , (uncluding the unconfirmed ones) impact craters in Australia.

Somebody tried to automate the exam taking? Without ever stepping inside a school?

The problem is not the size per se.

The problem is that every time you open a slashdot page, 1.1MB of (minified) JS code has to be parsed by the browser. Every damn Time.

No managed language (especially of the "everything is an object" garbage collected ones) are capable of parsing that in a reasonable time below 1s.

In dial-up times everything was slow because the "last mile" was slow. These days it is slow, because "web designers" effectively became a synonym to "mentally retarded hipsters".

Look at the slashdot. It would take probably 50-100 lines of PHP (or Perl/CGI) to create the main page and comments page(*) each, which would (A) take fraction of RAM/CPU resources and (B) load effectively at the speed the DB needs to fetch the data from disk (if they are not cached) (because disk is the slowest link in all that). Another smallish CGI for the login/logout. Throw in 50-100 lines of the CSS for the visual style. And probably 50 or so lines of the JS for the comment form. And another CGI for posting the comment in DB. And that's about 99% of the Slashdot I ever use. Now compare with the unmanageable clusterfuck we have. Or worse: compare to the beta.

(*) The tree organization of the comment might take bit more code.

I see where you coming from and actually I do not disagree with you.

Basically we just have different priorities.

Add-ons have literally unlimited access to the FireFox innards. That's by design. That's why FireFox add-ons are actually useful, compared for example to their castrated and harmless Chrome counterparts.

If you want to blame something, blame FireFox' rolling releases strategy. It's basically a cat and mouse game: browser changes, add-on authors has to change the add-ons, by the time they are finished, browser changes again.

Because plug-in requires at least a GUI widget. And a GUI widget has access to the event queue. On Mac and Linux that can be coded around - but on Windows you are stuck.

There is no better model currently which satisfies the performance and integration requirements. Plug-ins are black box binary libraries with hooks, allowing browsers to hook the plug-in into the browser. (That's why the browsers do the land grab they do, integrating everything possible or not inside them: they try to make out of the black boxes the white boxes. The obvious issue that leads to is the overstretching of the limited development resources. A team can handle only so much.)

Browsers already do the only effective thing they could do: run plug-ins in their own isolated processes.

P.S.

The greater irony (or more like "WTF" moment) is that some Google services actually work better in IE than in Chrome.

Rolling releases my ass. Everybody knows how IE works/doesn't work - stagnation is another word for stability. - nobody can be ever sure about the Chrome. Apparently even Google. Because its version number changes sometimes every day. (Well, it is easy to spot Chrome installing the updates: instead of the usual ~15s to fully start, it takes more than 30s.)

Slashdot is pretty "lightweight" and yet:

The size of JS embedded on this page I'm replying from is 33K in about 890 lines of code.

Externally loaded libraries are (most minimified):

http://a.fsdn.com/sd/all-minified.js?release_20150309
http://player.ooyala.com/v3/85...
http://a.fsdn.com/sd/html5.js
http://a.fsdn.com/sd/comments-...
http://www.googleadservices.co...

Total size: 1147446 bytes, aka 1.1MB.

You are welcome.