Think of it as evolution in action. You can stay on one planet while some disaster takes it out. We have lots of choices of disaster, don't we? The human race can continue via those "space nutters".

Sure, we should try to avoid the disaster, etc., but planets are not forever.

Per the NYC Department of Education children 5 and above are expected to walk up to 0.5 miles to school. Children between 5 and 11 are expected to walk up to 1 mile, and children 12 and above up are expected to walk or bike up to 1.5 miles to school.

Being run over by a car is by far the most likely tragety to occur to a child walking home from school so I looked up ped/bike fatalities in Maryland, and it is 1.88 per 100,000. This is actually lower than NYC, which had 2.00 such deaths per 100,000.

GC tuning can do a lot, but yes, huge heaps where the GC cannot keep up with the rate of garbage requires a full stop the world collection. However, if your application is really keeping a 15 gigabyte working set, I suspect you'd hit problems with fragmentation and memory leaks using something like Rust long before scaling to such sizes.

For a very long time, tape drives and media gave tape drives and media a bad name.

Consumer QIC — about 1% of tapes actually held any data, total snake oil that took 10 days to "store" 10 megs (immediately unreadable in all cases)
4mm — Tapes good for one pass thru drive; drive good for about 10 tape passes
8mm —Tapes good for maybe 10 passes thru drive; drive good for about 100 tape passes before it starts eating tapes

For all three of the above: Don't bother trying to read a tape on any drive other than the one that wrote it; you won't find data there.

Real QIC —Somewhat more reliable but vulnerable to dust, magnetic fields; drive mechanisms not robust, finicky about door closings

Basically, the only tapes that have ever been any damned good are 1/2 inch or wider and single-reel for storage. Problem is that none of these have ever been particularly affordable at contemporary capacities and they still aren't. Any non-enterprise business should just buy multiple hard drives for their rotating backups and replace the lot of them once a year.

And they ALREADY have expertise.

A computing expert already has decades of highly detailed experience and familiarity with a bunch of paradigms, uses, and conventions.

Experts are the LAST people that want to read manuals for basic things they already have extensive experience with, like desktop environments. Again, they're busy. Being experts.

So, reading the manual on new tech that needs to be implemented in a complex system—great. Reading the manual on a desktop environment? Seriously? That's the last thing an expert wants to be bothered with. "I've used ten different desktop environments over thirty years. Can't you pick one set of conventions I'm already familiar with and use it, so that I can apply my expertise to the actual problems I'm trying to solve? Why reinvent the wheel in such a simple, basic system?"

DEs should leverage existing knowledge and use habits to enable experts to get their real work done quickly. For an expert, using the desktop is NOT the problem at hand requiring a solution. It's not what they're being paid for and not what they care about. Experts love to learn new things—in their area of expertise.

So sure, desktop environment developers probably love to poke around in KDE's front end, code, and docs. But anyone else? People that are not DE specialists are not so excited about the new learning project that is "my desktop," I assure you. The desktop is the last thing they want to be consciously focusing on over the course of the day.

Why don't you watch the talk and find out?

Actually I'll just summarise it for you. If you run a lot of Tor nodes you will eventually get picked to host a hidden service directory. Then you can measure lookups for the entries of hidden services to measure their popularity, and crawl them to find out what's on them.

The tree widgets on the left are mismatched: some solid lines, some spaces with alphanumeric characters; the alpha characters are black, yet the lines are gray visual noise that creates visual processing and cognitive load for no reason, adding nothing.

The parenthetical text at the top has a title whose margin (left whitespace to other widgets) is significantly different from the text below it; there are spaces between the parentheses and the text, which no text or print style guide in the world endorses because it separates the parenthetical indicators from the parenthetical text, when they should be tightly bound for clarity.

The window title preserves the absurd convention of using both the binary name and a descriptive title together, and separates them with a typographical element (an em-dash) which is inappropriate in a label or design element because it is asynchronous—it indicates a delay in interpretation and pronunciation (as the em-dash just a few words ago in this paragraph does) and thus suggests long-form reading, which is not the intent for at-a-glance window titles (unless you don't want them to be very usable).

The title of the list widget, "Information Modules" is superfluous and redundant; the user starting an "About" dialogue expects to see "information" from the start, and they do not need to know about implementation ("modules").

The resize handle contrasts significantly with the window background, drawing undue attention to this particular area of the window above others (why is it "louder" than the window title, for example? Window controls should be secondary to window content and all at the same visual "volume" for usability).

In short—they still don't get it; they are signaling, in conventional ways that most users process subconsciously, thought habits and forms of attention that are not contributing to efficiency and use, but rather detracting/distracting from it. This is the same old KDE with poor, unprofessional design that leads to cognitive clutter. It's not that KDE has "too much going on" but rather that KDE has "too much going on that isn't actually functional and adds nothing to users ability to get things done).

Yuck.

[Java took a very different approach to the problem of "how to we get rid of segfaults and memory corruption". Java basically banned all interesting use of the stack, forcing everything onto the heap, and barred developers from using RAII. Nowadays, with more advanced compilers able to do advanced lifetime analysis, we can reconsider languages - such as Rust - that take a less draconian approach.]

I think it's rather misleading to state that more advanced compilers have obviated the need for Java's approach.

Firstly, Rust doesn't solve automatic memory management like garbage collection does. Their solution appears to be basically smart pointers with move semantics + reference counting for the cases where data doesn't have a lifetime cleanly tied to scope. Well, great. It's back to the 1990's and COM. Reference counting notoriously cannot handle cycles, which are very common in real programs. Any tree structure where you want to be able to navigate both up and down, for example.

In addition to the difficulty of breaking reference cycles and preventing memory leaks in complex programs, refcounting also has poor performance especially if you want threads involved. Garbage collection has now been optimised (in good implementations like HotSpot) to the point where it's faster than refcounting.

If we start seeing teams of non-expert programmers writing large programs in Rust, you will see programs with memory leaks all over the place.

Additionally, you realise that Java compilers have got smarter over the years too, right? HotSpot can stack allocate objects in a bunch of different circumstances, when analysis reveals that it'd be safe.

But they can earn 3x as much by going into the non-academic private sector and doing their research for profit-driven corps that will patent and secret the hell out of it, rather than using it for the good of all. Because the general public doesn't want to own the essential everyday technologies of the future; they'd rather it be kept inside high corporate walls and be forced to pay through the nose for it to wealthy billionaires.

And because bright young researchers actually have to eat, and actually want a life, they grudingly go where the money is, knowing full well they're contributing to deep social problems to come. Myself included.

But why would I settle for a string of one-year postdoc contracts that pay like entry-level jobs and require superhuman hours and commitment when I can go earn six figures at a proper nine-to-five, with revenue sharing, great benefits, and job security? Yes, the company owns everything I do. But I get to pay my bills and build a personal future. Of course, society's future is much dimmer as the result of so many people making the same choice that I have, and so much good work ending up in private hands rather than public ones.

But them's the beans. If you want to own the future, public, you've got to be willing to pay for it.

Basic Income is welfare, not something that sounds like it. The difference between it and normal welfare is, everyone gets a basic income whether they want it or not. It's meant to be enough to live off.

The idea of a BI is a very old one. It has nothing to do with cryptocurrency, and I'm not sure what relevance cryptocurrency has (and I say that as a Bitcoin developer, so I'm a fan of CC in general). In theory a society rich enough to afford it would have moved to the oft-fictionalised post work utopia that you sometimes see in things like Star Trek. Because everyone gets it whether they want it or not, unconditionally, the basic income would be supposedly stigma free. Thus if you want to pursue things that are not very profitable but are beneficial to society nonetheless (production of art, charity, etc) then you could do that and not have to worry about being seen as a welfare sponger.

I love the concept in theory, but a society rich enough to afford one is pretty unimaginable in today's world. Western societies are clearly incapable of even providing the current levels of welfare let alone a vastly larger level. I see a BI as a useful goal to inspire people about the future rather than something practical for today.

Hopefully we'll find out eventually.

I think you are missing the application for an Open gate array.

It is not really for you and your company. You don't have any particular interest in the open part, and thus you and your company don't fit the demographic of the sort of user we would want. We don't need your money. I can do the first runs of this using Mosis and its ilk for chump change, and go from there.

It simply doesn't matter if it's 32 nm or 15 nm or 50 nm. What matters is that the user can completely understand the bitstream and produce their own tools for it. We have no shortage of users who want that.

It doesn't matter if it is on the leading edge in terms of cost, speed, power, thermal efficiency, or size. It matters that it's open.

And maybe we can do something that you can't do with any integrated circuit available to you, which is verify from first principles that the manufactured device is without deliberately hidden security back-doors. Because we don't have intellectual property to hide and thus we don't mind producing it in a way that would make it capable of being examined.

So, I am not particularly worried about what foundry I'll use and whether I can compete on the same playing field as Xylinx and Altera. I have my own playing field, with radically different rules from the ones they are using. I have my own customers to satisfy.

https://www.paypal.com/us/cgi-...

Clear form, quick payment w/o entering lots of credit card details, every non-international USPS option, no need to mess with the weird postal service website.

One well-known market would be immediately available and very eager to embrace an open FPGA, namely EE education.

Yes. EE education and academic research.

There is also the security problem. How can you determine from first principles that the chip really contains what it says it does? Insoluble with any commercial component. Maybe we could make ours sufficiently visible.

So, my feeling is that we could get a grant for this.

There's a partial list of fabs at Wikipedia. There are more than just those three.

Sure, process optimization per fab is an issue. We would probably need to start on the very conservative side.

A lot of the time, building a custom ASIC rather than using an FPGA just isn't an option. Most of the products I'm concerned with need to be programmable.