The only time I could ever see us adopting new calendar systems is when (if) we eventually migrate off-planet into space colonies or onto other bodies in the solar system. Why? Because only then will each colony have a completely different notion of what a solar year is, and different (or even entirely artificial) notions of solar days. In these colonies a standardized calendar system may arise. Or a chaotic web of independent calendar systems.
Perhaps just a count of seconds from some zero point. Mark intervals in kilosecs and megasecs. Then the computer time-counter register will be the only clock anybody needs. Never mind 'Wednesday'. "See you in a megasec!" which is about 11.6 of our 'days'.
This attitude is exactly why Linux has such a horrible, horrible packaging experience. Building cross-distro packages is awful. Teaching users how to install packages is awful. Installing custom apt sources or repos to get newer versions of packages is awful. And we're getting stuck up on some inconsequential thing like a library will be duplicated. Guess what, OSX has been doing it successfully for years.
The Linux community is missing the forest for the trees.
Can we please stop talking about these "laws" that are based on absolutely nothing but observing an apparent trend that may not continue past tomorrow? Seriously, spoken to too many undergrads who think there's some sort of physical process or causal relationship driving Moore's law. It's bullshit. It's just people saying "growth has been this fast, and I don't know why, but I sure hope that growth continues to be this fast!"
Are there plans to work on integrating PGP encryption? N1 really looks nice but there are many people, like me, who can't move over until it gets e-mail encryption support.
I'm kind of enjoying watching the developer community turn on Drupal like a pack of wolves. That said, aren't performance issues more or less unavoidable when you're dealing with a CMS? The scope of use cases they try to cover is pretty wide which is sure to lead to bloat.
I deal with Drupal (7.x) on a daily basis, so that's why you'll probably detect bitterness from me. Personally there are a myriad of reasons why Drupal rubs me the wrong way, most are Developer issues though (Such as their annoying comment form API, and arrays, arrays everywhere).
There are better CMSs out there, IMO, but we have to use Drupal because it's the only one that has a Certification of Networthiness (I work in the DOD) - and to make things worse for us, we have to use Drupal on IIS with MSSQL (for now). Why can't we just go with Umbraco (.Net)!?
I've been working with Drupal professionally since 4.7, have code in several contributed modules in D6 and D7, and used to organize the local Drupal User's Group. I know all about the bitterness. I've spent the last 10 years watching a lightweight and infinitely hackable CMS turn into a bloated morass of opinionated overweight APIs that make easy things complicated. Yeah I'm looking at you renderable arrays.
Anyway I'm counting the minutes until an Acquia PM spots this post and starts spraying down the comments section with 35 paragraph word salad breathlessly defending the heroic efforts of the core dev team to drag D8 into the 21st century, in the process entirely missing the point that this may very well be the first core release of Drupal that will not run on commodity hosting due to resource requirements.
Note: I am not an Acquia PM. I am just someone who sent in a few core patches over the last 11 years.
When I got aboard Drupal core was a very lightweight CMS. Infinitely hackable, yeah, if you go and hack core. Been there, done that, got the T-shirt. Time flies, years pass, and contrib modules happen because users want to click in a browser and not hack core. CCK. Views. All that jazz. Maybe your core is still lightweight but surely not your whole site. Comes Drupal 7, we move some of that into core. Core near collapses under the tech debt incurred. Remember the issue "Field attach API integration for entity forms is ungrokable" reported by the ... field API maintainer. Opsie. So the core developers try to decrease that tech debt and move towards something they found desirable. That's how Drupal 8 came to be.
Dissing Acquia for core when the chief architect of everything wrong with Drupal 8 (who have basically pulled a fast one over the community in an ingenious breach of process) is not working for Acquia is pointless. There are quite a number of things you could diss Acquia for, there's no doubt, but core is hardly one of them. In fact, they paid Wim Leers to undo as much of the performance damage -- by introducing vast amounts of caching -- as possible.
Hold on bub, you're trying to tar me with the "Acquia-has-taken-over-core" conspiracy theorist brush and that's not what's happening here.
I'm dissing Acquia for their history of ridiculous marketing blasts that try to convince IT managers to upgrade to Drupal $N 18 months in advance of the contrib module space becoming sufficiently stable to seriously consider platforming a production environment on top of. Also for their PMs skulking around in various media channels breathlessly defending Drupal from any criticism regardless of accuracy.
I've been intermittently following your attempts to get various core initiatives to back away from the metaphorical ledge off and on since DC Portland. Sorry for all of us you weren't more successful.
> Dissing Acquia for core when the chief architect of everything wrong with Drupal 8 (who have basically pulled a fast one over the community in an ingenious breach of process) is not working for Acquia is pointless.
where can I read more about this? I enjoy good programming drama
https://www.drupal.org/node/1874530 everything in this (short) issue is a lie: submitted as "Proudly Found Elsewhere" when a significant portion of the code was written by the author of this issue, just submitted upstream and then pulled downstream (check @author tags, it's right there but https://github.com/symfony-cmf/Routing/commits/master?page=9 also here for the sake of archives, commits start at 3b152c4) to avoid usual scrunity by downstream (ie the normal Drupal core review process). To avoid anyone catching this (and I haven't caught it for a very long time) it was submitted on Dec 26 when everyone is obviously away.
I have no idea how the core committers didn't catch all this -- but you can't really blame them, there was a gigantic pressure to move ahead. And then based on this foundation, everything link related, inbound and outbound was converted to route names instead of paths which is a) absolutely unnecessary b) destroys performance.
Of course, there was history and reason trying to avoid review of this pile of code. Symfony, in general, is an extremely poor fit for Drupal: Drupal was a convention based system and Symfony is very heavily a config based system. The most obvious and very glarring misfit is hooks vs events and despite hooks being the central Drupal building block there never was a fundamental, through research as to what if anything to replace them with. Compare the scrutiny Symfony Foundation received in https://groups.drupal.org/node/167299 to how Symfony HTTP Kernel got added: via an admittedly "off-the-cuff" prototype https://groups.drupal.org/node/198538 . Note that I was trying to push back on this immediately with little success then or ever. So after shoehorning HTTP Kernel in over some bitterness and fighting it stands to reason the architect wants to avoid any scrutiny this pile of code would receive.
PHP's speed is here is a bit of a red herring. I dislike linking to benchmarks, but https://www.techempower.com/benchmarks/#section=data-r12&hw=.... In I/O bound situations, PHP performs within an order of magnitude of C. You don't have to be Facebook, you literally just need to enable APC or XCache.
Let's focus on how horribly awful Drupal is. Or, to the point of the topic, let's congratulate the author for discovering that yes, you can in fact replace a single server with any number of cheaper computing devices (you just have to disregard all of the other reasons why we use servers).
I'm an independent developer. The majority of my clients are on Drupal. Here's what I've learned:
While it's true that someone looking at Drupal's architecture for the first time is likely to say, "Whaaaa? Why, why, why?", the truth is that a lot of the decisions start to make sense once you need a CMS for more than a basic blog.
For example, the reason there are so many joins just to retrieve all the fields of data for a page is that Drupal allows each field to be shared across different content types, or to have different revisions, or even to have different translations from other fields on the same page.
Yes, this is going to feel awkward and slow if all you need is a simple blog post table with one post per row. But if your site is complicated enough or has enough traffic, chances are that you're going to start relying on caching to help out, no matter what CMS you use.
Drupal's no different. There's its own internal caching (which bypasses most of the queries for anonymous users), PHP's APC caching (which gets over the PHP loading hurdle), memcache (to bypass queries for logged in users), and Varnish (bypassing Drupal altogether for static content.)
I know it's been mentioned above, but PHP is very much not slow on its own. On that particular benchmark it's the highest interpreted language on the list (same with single query, fortunes and data updates). In fact, despite some atrocious language design, speed hasn't been a problem in a long time. And that's just PHP5, PHP7 offers claims of 100% speedup, not to mention HHVM.
I would wager that the typical bottlenecks are where the slowdowns are happening, and your hints about the # and types of queries would be my first guess.
Drupal isn't alone here. Mediawiki without caching does some horrible stuff. I just loaded a random page (with caching turned off) that does 1874 database queries. For one page. That it still loads in 7 seconds is a miracle.
That never happens though. Drupal has to bootstrap itself so it loads it's registry cache, variables cache, current user record (split across at least four tables to pull in the user account, associated roles, and user access permissions), any dynamic menu builds are going to the menu table, access callbacks and other function calls associated with dynamic menu rendering may also trigger other database calls, uncached content blocks have to be pulled out of the database, and we haven't even gotten to loading the node for the page which could be split across a bunch of tables if the content type has fields added to it...
Drupal has always performed like shit. 10/sec is actually pretty good for Drupal It's only good for managing static content, the only way you get any sort of performance out of it is super aggressive caching.
PHP is a slow abomination. The entirety of Drupal and all modules have to be bootstrapped and run on every request. It runs far too many SQL queries and those queries look atrocious (nested selects, tons of joins, etc).
Same with Magento Commerce. I was always shocked at just how slow it is.
It gets pointed out below, but I think that is really important.
> PHP is a slow abomination. The entirety of Drupal and all modules have to be bootstrapped and run on every request. It runs far too many SQL queries and those queries look atrocious (nested selects, tons of joins, etc).
Those statement don't go together. If it is drupal that is doing too many requests, that is not the fault of PHP.
I'm working partly on an PHP open source blog engine and we are getting way better results. Though caching also helps there, as soon as the SQL statements are properly cached performance increases a lot. That will be true for Drupal, but it most likely will be true for any other CMS that has an equvalent workload on every request. And that those caches help actually show that PHP is not at fault.
I think the way to read that paragraph is as two separate statements.
>PHP is a slow abomination. The entirety of Drupal and all modules have to be bootstrapped and run on every request.
and
>It runs far too many SQL queries and those queries look atrocious (nested selects, tons of joins, etc).
So the first part is about slowness due to how PHP is usually run. The second part is about slowness due to the implementation of Drupal.
When I say "how PHP is usually run", I mean that strictly speaking one could probably write PHP in a way such that there is one part which comprises all the things that take most of the time to load and have this run standalone. However, I think going to such extents might be more work to do in PHP compared to picking another language. Then again, I haven't written PHP for several years and even when I did I never did any advanced stuff so for all I know what I'm saying here might be something PHP professionals have already thought of.
In my benchmarks, for accessing databases, string concatenation and output, PHP is faster than Nodejs, Go and Python and is on par with Luajit. So no.
And it's not PHP's fault that Drupal and Magento developers don't care about performance and think caching is a solution to all performance problems.
>>The entirety of Drupal and all modules have to be bootstrapped and run on every request. It runs far too many SQL queries and those queries look atrocious (nested selects, tons of joins, etc).
Agree with the above. However, PHP has reactphp which Drupal could have used.
You're thinking of Drupal 6. Or maybe 7. Drupal 8 (if you use a released version) gets thousands of requests per second. To be fair, that's because it aggressively caches page components and uses cache tags like a demon. But that's the ootb configuration, no special tools required.
This comment is brilliant. To those who consider Hegel important it says one thing. To those who can't stomach him it says another. Those who have never heard of Hegel will also be partitioned, into those who go to wikipedia and get confused, and those who take it as more support for their feeling that big words aren't so bad.
"Hegel's principal achievement is his development of a distinctive articulation of idealism sometimes termed "absolute idealism,"[8] in which the dualisms of, for instance, mind and nature and subject and object are overcome. His philosophy of spirit conceptually integrates psychology, the state, history, art, religion, and philosophy..."
"He started Hegelianism and is a part of German Idealism. He influenced many writers and philosophers, including those who agreed with him (Bradley, Sartre, Küng, Bauer, Stirner, Marx), and those who did not agree with him (Kierkegaard, Schopenhauer, Nietzsche, Heidegger, Schelling). Hegel's books are difficult to read and deal with many different ideas at the same time. He has written about history, politics, religion, art, logic and metaphysics."
> Congress shall make no law [...] or abridging the freedom of speech, or of the press