You could easily argue that it was a coincidence. This was also the post-WWII period, when much of Europe's industrial capability had been blasted to smithereens. There was a huge boost in demand and we were the country with the infrastructure in place to handle it.

Anyway, my point is not about the income tax rate. It's about the laughable idea that it punishes Mr. Big at the top. $90 million is nothing to the real players in and out of government who pull the strings. An absolute joke. And giving the money TO the government is just handing it to many of the same players. And the government has ZERO accountability to make productive use of the money.

And also, it's about the fact that the debt-based economy is a bigger tax than the income tax, and no one realizes it.

You really think that would change anything? Hey, let's take Mr. Evil Corporate Guy's money and give it to the government! Who do you think runs the government? Who do you think Equifax is? It's essentially a wing of the government already, and it was intended that way from the start.

Ask yourself why an Equifax should have such a say in the average American's life? Why do we live in a society where 99% of the people are in debt their whole lives?

I absolutely agree anyone is free to set up a free website and pay for it with their own money... and many do. I also agree that anyone is free to go to a website that supports itself with ads. And any website that uses an *honest* ad system (I.E. serving them from their own server) can't even be subverted by Brave.

And, anyone is free to keep on supporting the current web, disaster that it is. We all have choice, at this stage of the game. I'm saying Brave is the only sane choice for the greater commercial web. I'm all for community wireless and all that sort of stuff. It's not going to scale. It's not going to replace the big web. Commerce happens. Call it greed all you want, that won't change how life works. I prefer a consumer-choice based approach that lets us at least reign in the corporate insanities, which is what Eich is trying to do.

It's actually the only sane approach to the modern web. The web can't be "free". Someone's got to pay the bills. It either has to be ad-supported or subscription-based. Think about it: if you go subscription-based for everything you are MUCH more trackable than an ad-based web.

The current ad-based web is an absolute nightmare. The average person who doesn't know the magical combination of browser add-ons ends up with a frozen browser several times a day. Try to even have 6-7 tabs open in Chrome or Firefox and you end up with problems.

Not to mention, the current ad-based web is scary intrusive.

If you read the details on Eich's approach:

1. He is protecting your privacy. Ad impressions are guaranteed on the buyer side, but your identity is protected. That is built in.
2. He is not "choosing" the ads you see. You get to choose the type of ads you will see, based on a blind profile that doesn't reveal your identity to the advertiser
3. It places sane limits on the number and placement of the ads.

I've been on the web since day one. I never minded a moderate amount of advertising. Anyone who does is a ridiculous sourpuss of a human being. What I mind is them ferreting out my identity, and ruining decent websites with ads that pop up, or under, or run extravagant javascript code that crashes my browser, or... Flash, just anything Flash, or auto-playing video and audio, etc... If we can get rid of that, I'm all for it.

I have had exactly the opposite experience as this "journalist". Upon re-watching Episode 4 after more than 20 years, I was struck by how superior the set design and and acting was to the prequels. Yes, it's nowhere near as glamorous or sheened to perfection by CGI, WHICH IS EXACTLY THE POINT. Everything had an authentic air to it that you just don't get later on. And this magic is strongest in the first two movies.

I Tor'd the original Han-shot-first edition, of course, and watched it looking intently for any real gaps in continuity or jarring inconsistencies in the sets, costumes, etc... none. It really was a work of art, top to bottom, in spite of the low budget.

I mean insanely more complicated than jails, not insanely more complicated than other standard VMs. Have you used jails? I was on a project to deploy Docker instances on a large scale, and it took me 6 months to create an infrastructure that could have been done in 1 month with jails. I will agree that Docker has some nice abstractions, but the details and special cases and workarounds were endless. And I still don't see the actual advantages over FreeBSD. There's simply nothing stopping one from creating a few shell scripts to spin up thousands of BSD jails, mapping drive storage and networking however you want. A lot of this stuff the Linux guys are thumping their chests over now was in mass deployment over a decade ago in certain BSD hosting companies.

Yes, that's a good start, but remember that Docker also has a... social landscape I guess we could call it. There's a central website and blog, and then there's the all-important Docker Registry where you can search for existing images, and build your own images on top of base images you download. And Docker has a built-in feature to fetch images right from the registry. Makes it very easy to experiment and toy around with images.

Docker made these seemingly superficial things priorities from day one, sometimes at the expense of good architecture and security. For example, earlier versions (as of 1.2 AFAIR) did not have an easy way to delete built-up cruft from images you had imported.

So the challenge would be to accomplish these benefits without some of the huge gaping security/stability/malware holes that Docker has had to deal with.

Sounds like a thing that needs doing. Where do we start?

So what we have is an insanely more complicated way to manage your "VM-ish" things, a really, really odd way of approaching your containerized system where it doesn't actually get to have a full userland (no SSHd, etc...) unless you do all sorts of insane tweaks (believe me, I know because I spent the better part of last year doing this), and in the end the only real advantage of Docker over jails has nothing to do with the intrinsic design of the system, but the build infrastructure surrounding it?

That sound about right. All FreeBSD needs to compete with Linux containers is an image repository and a Git-like method for managing and building images. There are already tons of jail management tools for snapshotting, migrating, moving, templating, etc... And given that jails have a much longer history and are likely to be much more stable and easy to manage, it seems like a natural next step, BSD guys. Hint, hint...

Of course you have to have built on things throughout your career TANSTAAFL and all that. Point being, think strategically. Play to your strengths and to the true underlying needs you can meet, rather than chasing after the hot new technology trend that can have you chasing your tail.

But age is not the whole story. I didn't become any kind of developer until around 33, and certainly had no serious understanding of databases until my late 30s. And yet, here I am, a very much in-demand expert.

Bingo. The real key is to go deep on something and specialize. As a web application developer approaching 50 who did a lot of database work, I realized I had put serious time into learning the ins and outs of the relational model, SQL, business rules thinking, etc... and I had also put lots of time into understanding Linux. Turns out database and Linux skills are in high demand. So I've dropped most of the web app programming (Honestly, in that domain you are competing with a worldwide talent pool, most of whom are willing to work cheaper than you) and really strengthened my enterprise database skills. I now do PostgreSQL consulting almost full-time, and really it is a pleasure to do more serious knowledge work instead of constantly scrambling for scut-level web application work.

Also as you age, put more time into the things that change least. SQL isn't going away anytime soon. Ditto for Linux. Web app frameworks change every freaking *year*. Leave that stuff to the young guys.

How do OIDs solve this? Updating a record it still updating a record. OIDs don't magically make that problem go away.

One solves this problem the way one solves any other data problem: logical thinking and planning ahead. If you are creating a long-running business application where things like addresses may change, you design your database to take that into account. You store a timestamped address with every order record, or you store multiple addresses by date range. It's not exactly rocket science.

There is literally no reason to use OIDs except as a crutch when one has created a table without a primary or candidate key--and even then OIDs won't save you from bad logic, such as duplicate records or other idiocy.

BTW, it is important to also remember that OIDs are not enabled by default for new table creation. Many times the PostgreSQL core team has discussed whether to deprecate OIDs completely. The decision was made to keep them for two reasons: a) some applications still depend on them, however misguided their reasons and b) Some PostgreSQL add-ons and external solutions (replication, etc...) use them.

I wouldn't even recommend bothering with hstore. There are several even better ways to use Postgres in a "NoSQL" setting.

For example there is the Mongres project, that lets a PostgreSQL database emulate the MongoDB protocol. So you could literally drop Postgres into a Mongo-powered application with not a single hiccup, and get a) better performance and b) all the back-end relational stuff you need when it comes time to do reporting or other business logic.

There's also the new JSONB datatype in PostgreSQL 9.4, which I would recommend over hstore if you want to just store "free-form" data in records.

EnterpriseDB did a very well-thought-out study on PostgreSQL/NoSQL.

That's not even close to what "referential integrity" means. In fact, it could be used to accomplish quite the opposite.

OIDs are one feature of PostgreSQL that should be buried inside the implementation and not allowed to be accessed from the developer side. Otherwise you are pretty much completely going around the whole point of the Relational Model. If you are developing an application in such a way that it needs pointers to rows, you might as well just store data on the filesystem and be done with it. Or use one of those fancy NoSQL thingies and enjoy your data corruption.

"Lifting heavy" is relative to one's capabilities, genetics, age and so on. I don't mean you should lift beyond capacity to control a weight or keep proper form. And, lifting light is how you repair joints, IMHO. If there are joint problems, start light, do high reps, slowly and carefully focusing on range of motion and keeping joints seated right. Then as the body begins to adjust, gradually add weight, but never to the point that you are sacrificing form. Also, lifting heavy is only a small component of good fitness. Other sorts of high-intensity work (like rock-climbing, sprinting, swimming) help round out the picture, and I think even low-intensity exercise (long walks) fill out the picture completely. That which is highest intensity should be done to shortest duration.

Some people don't add a lot of muscle mass, but small gains are still gains ( Usually offset by fat loss, making the subject think nothing's happening). If you are adding strength you are going in the right direction.