And how a (almost) stateless protocol like QUIC supposed to handle the packet loss any better?

The previous write-ups about the Google protocols were all like one based on the premise that packet loss is a very very rare occurrence. That's why they use effectively a stateless transport: because they assume that errors are rare. In other words, they are too very bad at handling it.

Coming from the old days of IPX vs TCP debates, I remember how the IPX proponents were going abruptly silent in the face of a bad network connection: IPX wasn't able to transfer literally anything, while TCP slowly was churning data, allowing to download OS update and fix the issue. It would be hilarious (and not unexpected) if (or rather when) Google would step into the same cowpie.

3D graphics is an outlier in the driver development.

But for a useable desktop, 2D graphics is sufficient. The 2D is commonly supported via GPU's ROM and as such implementing a 2D driver isn't hard.

Even 3D in itself isn't as hard. The problem is that games require (A) lots of edge cases optimized and (B) huge number of acceleration features implemented.

Writing drivers isn't hard.

But for the broader acceptance of an OS, one needs a whole shitload of them.

In the past, a computer with a half dozen devices was "packed". Today? A cheap tiny ARM SoC easily runs up to 30+ built-in devices.

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?