Dmitri Pisarev dimaip

Here are my estimates in Astra's notation: N = written without Peter's sanction; C₁ = substantially composed during Peter's life, by him or on his commission; C₂ = completed after his death on a real commission he gave beforehand. A factor above 1 favours N and below 1 favours C. "N/C₁ = 2" means the evidence fits N twice as well as C₁.

Each point

Point	N/C₁	N/C₂	Why
Name form Συμεών and the Transfiguration details	0.8	0.9	They point to someone close to Peter's tradition. That fits C best, but an insider writing without sanction counts under N.
Apostolic signature	1	1	Both hypotheses predict it; the motive question is scored separately below.
Motive, and ordinary polemic without forgery	0.85	0.85	Real but modest support for C. The letter's argument does rest on Peter's eyewitness authority (1:16–18, 3:15–16), so a writer without sanction had a specific motive.
Style: elaborate Greek, unlike 1 Peter	1.2	1.0	Neutral if there was a skilled co

I read the whole export: 609 messages over about 45 hours. Tigran wrote 110 messages (~51k characters), you wrote 26 (~12k), and Ergo wrote 470 (~317k).

1. The dispute itself

My view: 2 Peter wasn't written by Peter. Someone wrote it in his name after his death, probably somewhere around 80–120 CE. I'm fairly confident Peter didn't compose it himself. I'm less sure whether he could have commissioned it while alive. You were right that this is one of the more settled questions in NT studies, and you could reach the same answer from the evidence alone, without leaning on consensus.

Here's what I think the debate underweighted.

The external attestation was never actually argued. Tigran kept setting it aside ("we'll get to reception later"), and the chat ended before he did. Meanwhile he collected verdicts of the form "excluding reception, my hypothesis is slightly ahead." That means "excluding the strongest evidence against me, I'm winning." A letter claiming to be from the leading apostle has n

Dear Neos community,

during the last code sprint in Vienna I've spent a week coding support for selecting multiple nodes in the document and content trees and performing batch operations on all of them: copying/moving/deleting/hiding all of the selected nodes at once. I am sure editors are going to appreciate this feature very much :-)

Now the feature is already working, but I still need the time to polish the technical implementation, writing tests for it, improving the visual styling etc. Unfortunately, I will not be able to finish it in a spare time mode in the foreseeable future, so I want to ask you to support me by funding this feature. I need about 10 hours of work (at 55€/h rate) for polishing it.

If I get another 20 hours of sponsoring, I would be able to implement batch editing of any property in the inspector that is common to all of the selected nodes. E.g. imagine selecting multiple nodes in the tree and then being able to set say a starti

Here's a quick idea for a stateless PaaS on top of Github and docker swarm.

You mark Github repos that you want to deploy to your Docker swarm with a certain tag, say "my-server".
Each repo has a docker-compose.yml file defining the stack needed to run it.
You have a daemon that periodically queries Github API for repos with given tag name (and from a certain user, for security reason). For every found repo it would do docker stack deploy RepoName --compose-file "...". Stacks would be deployed according to given service's deploy policy, utilizing its healthchecks etc.

So if you need to add a new repo to the swarm, you just mark it with a tag and wait a few min. If you need to update a service, you just edit its docker-compose.yml file and wait a few min. Secrets would be managed via docker secrets.

Advantages over plain swarm cluster?

Dear community,

Neos CMS team is currently in the middle of UI rewrite on top of React. This project will have immediate benefits like improved performance, correctly working media-queries and higher robustness of the UI due to the use of iframe for site content. But main aim for it is to support ambitious plans of our project (such as structured editing of content) that would require a modern foundation.

Currently we have reached an alpha phase, where almost all basic functionality is in place, but everything needs A LOT of polish. And that's where I want to ask for your support.

I have been a part of this project since its early prototype days, and was able to spend quite some time working on it, including joining 3 code sprints fully focusing on it. But right now I can not afford to work on my spare time as much as the project currently requires it. So **I'm looking for sponsors that would allow me to relocate some of my freelancing time


	// Available variables:
	// - Machine
	// - interpret
	// - assign
	// - send
	// - sendParent
	// - spawn
	// - raise
	// - actions

	import React, { useContext } from 'react'

	interface Mark {
	type: string
	}
	export interface ElementNode {
	type: string
	nodes: Array<ElementNode \| LeafNode>
	data: {
	[item: string]: string

	<CardElement
	onChange={ev => {
	if (ev.complete) {
	const card = elements?.getElement(CardElement)
	stripe
	?.createPaymentMethod({
	type: 'card',
	card,
	})
	.then(result => console.log(result.paymentMethod?.card.country))

	prototype(Flowpack.FusionBP:RecursiveMenu) < prototype(Neos.Fusion:Array) {
	@process.tmpl = ${'<li>' + value + '</li>'}
	title = ${node.properties.title \|\| '<em>' + node.name + '</em>'}
	nextLevel = Neos.Fusion:Collection {
	@process.tmpl = ${'<ul>' + value + '</ul>'}
	@process.tmpl.@if.notEmpty = ${q(node).children().count() > 0}
	collection = ${q(node).children().get()}
	itemName = 'node'
	itemRenderer = Flowpack.FusionBP:RecursiveMenu
	}

	prototype(Sfi.Site:ImageUri) < prototype(TYPO3.TypoScript:Case) {
	image {
	condition = ${asset}
	renderer = ImageUri {
	asset = ${asset}
	width = ${width}
	height = ${height}
	maximumWidth = ${maximumWidth}
	maximumHeight = ${maximumHeight}
	allowCropping = ${allowCropping}