Una de las cosas que me gustan de las máquinas antiguas es la simplicidad y la parsimonia. Me gustaba SMF porque se sentía ligero y rápido incluso en un PC antiguo (o en una máquina moderna con la configuración de máximo ahorro de energía).
Al visitar el nuevo foro, he notado un mayor uso de la CPU y que la máquina se calienta más. Tratando de evaluar si es una coincidencia, he comprobado algunas cosas.
uMatrix informa de que el nuevo foro quiere cargar contenido desde stripe.com. ¿Tienen pensado incluir algún tipo de contenido de pago? Supongo que no. En este caso, ¿quizás podrían intentar averiguar si hay algunos módulos inútiles activados? Incluso podría tener un pequeño impacto en la carga del servidor y en los costes de funcionamiento.
Tanto el sistema como Firefox (about:processes) informan de un consumo continuado de CPU relacionado con las pestañas que muestran el nuevo foro. Al abrir las herramientas de desarrollador, aparece un temporizador y un texto que menciona el seguimiento del tiempo que los usuarios pasan navegando.
¿Es algo que han activado voluntariamente? No me gusta la idea de un foro para entusiastas de lo retro que consuma CPU todo el tiempo y haga llamadas a stripe.com. Grandes zonas de Internet se están «mierdificando» y entiendo que implementar nuevas herramientas conlleva nuevos costes. Agradecería que se desactivara esto.
Stripe se ejecuta de forma innecesaria y sin transmitir nada en realidad (sobre todo porque no tengo una cuenta de Stripe ) por la función de suscripciones. Lamentablemente, las suscripciones en Discourse están ligadas a Stripe. Y, aunque tengo pensado usar la función de suscripciones, no estará ligada a Stripe. Por desgracia, Stripe no se puede desactivar sin desactivar las suscripciones por completo, pero aún tengo que pensar cómo implementarlo. Al fin y al cabo, sigue siendo un trabajo en curso (WIP).
En cuanto a la función de rastreo… ¿En serio? ¿Te molesta que el foro rastree cuánto tiempo pasas en él, como básicamente cualquier otro sitio web? Tampoco es que se use para anuncios, minería de datos, vender la información ni nada por el estilo.
Editar: ah, también se usan temporizadores/rastreadores para decidir si enviar notificaciones por correo electrónico o notificaciones en vivo en algunos casos. Además, calcula si alguien leyó realmente una publicación o solo la miró por encima para otorgar niveles de confianza, recordar su posición de desplazamiento y calcular los tiempos de lectura de los temas.
(Por cierto, he usado esta función para eliminar bots)
No se puede hacer nada con respecto al mayor uso de recursos; es de esperar cuando te mudas de una plataforma anticuada a una nueva. Pero tengo que decir que funciona supersuave en mi portátil antiguo secundario.
Dicho esto, son puntos válidos y gracias por los comentarios. Pero llamarlas «antifeatures malévolas» es pasarse un poco
P. D.: Me encantaría saber más sobre lo que piensas.
Entiendo la necesidad de tener un poco de paranoia en esta época en la que las empresas son sospechosas de cojones, pero no creo que haya de qué preocuparse demasiado.
En el caso específico de aquí, SMF tiene funciones de rastreo similares, así que si no ha sido un problema durante todos los años que duró el foro antiguo, ¿por qué lo es de repente ahora que estamos usando un software de foro nuevo?
Aunque SMF era genial en cuanto a rendimiento, no era muy resistente. Se caía bastante a menudo.
El nuevo foro parece tener algunas funciones que, en mi opinión, no sirven para mucho (¿para qué necesita un foro un sistema de logros?), pero prefiero eso a no tener foro en absoluto.
A mi los logros y la gamificación también me parecen algo un poco tonto, pero están vinculados a cosas como los niveles de confianza (Trust levels), así que no estoy seguro de cómo gestionarlos. Personalmente, simplemente los ignoro.
En cuanto al rendimiento, SMF era de todo menos rápido. Entonces, ¿prefieres un sistema que tarda dos segundos (o más) en renderizar una página que luego se muestra de inmediato (no siempre, porque las llamadas continuaban después de eso), o una plataforma que le exige más al cliente (es una aplicación de una sola página en Ember.js) pero que te lo da todo sin despeinarse?
(Y mejor ni hablemos del mantenimiento que requería su “simplicidad”. Tienes que tener en cuenta los tiempos de inactividad. Por ejemplo, la razón por la que pudimos deshacernos de Cloudflare para la mayoría de los usuarios fue por las funciones antirrastreadores integradas de Discourse. ¿Prefieres que tu foro se caiga porque a Alibaba le dio por tumbarlo, o consumir un poco más de CPU y mantenerlo en funcionamiento?)
En primer lugar, muchas gracias por tu respuesta tan detallada. El nivel de detalle demuestra que de verdad conoces y dominas los temas. Por ello, todo mi respeto.
Tío
La ambigüedad del lenguaje escrito… Todos hemos mantenido la calma en todo momento, no te preocupes.
Stripe se ejecuta, …
¡Veo que entretanto has encontrado una forma de eliminar cualquier llamada al dominio de Stripe, genial!
Como dije en el primer mensaje, me molestaba el aumento en el consumo de CPU.
Jeff Atwood creó Discourse. Al igual que con la red StackExchange (StackOverflow, etc.), que también creó él, se aseguró de que fuera posible navegar por ella por completo sin nada de Javascript.
Aun así, Discourse parece «menos minimalista» y consume más recursos. Y a diferencia de StackExchange y SMF, tiene un aspecto completamente diferente cuando Javascript está totalmente desactivado.
Ah, dichosos bots.
Muchas gracias por explicarlo.
Tienes mi confianza y supongo que la de la comunidad.
Lleva siendo así durante décadas. Las plataformas crecen y se vuelven más lentas. En cierto punto, algunos consideran que la lentitud es excesiva y escriben desde cero algo más rápido, lo que inicia la siguiente iteración.
Respondido arriba tras tu invitación, y también a continuación.
Sigo teniendo un modelo mental cercano a la web original, que sirve principalmente documentos. Los programas (Javascript) son totalmente opcionales en el sentido de que cualquier cosa que pueda funcionar sin código, de hecho funciona sin un entorno de ejecución de Javascript en el cliente.
Por desgracia, a la mayoría de los desarrolladores web no les importa en absoluto y tienden a asumir que la CPU y el ancho de banda son ilimitados, que el navegador del visitante y el del desarrollador son el mismo, que toda la web está 100 % disponible y que las llamadas a dominios de terceros son gratuitas y naturales. ¿Por qué? Porque requiere menos esfuerzo que pensar en la diversidad por el lado del usuario. La pura verdad es que cuanto más dependes de algo, más cosas se rompen cuando algo en otro continente se cae. Y como las averías son raras, esas soluciones frágiles y recargadas se aceptan y se convierten en la norma.
Me gusta el mundo de CPC donde un byte o un ciclo de CPU es algo que te importa, no una unidad despreciable por varios órdenes de magnitud.
En fin, por orden de importancia:
¡La comunidad CPC vuelve a tener su sitio web principal (en mi opinión) en línea! Podré leer a otros, hacer preguntas, mencionar mis proyectos en curso, etc.
Te mereces el reconocimiento.
Es una gran noticia.
Discourse permite escribir publicaciones en Markdown en lugar de un WYSIWYG fundamentalmente defectuoso.
Sufro limitaciones como el número de enlaces o citas en una sola respuesta, lo que me obliga a recortar partes de esta respuesta.
Llega una respuesta larga para acompañar tu café matutino —y el de todos los demás.
Para empezar: quiero que tú —y cada usuario aquí— estéis contentos con el resultado y con la comunidad. ¿Que si todo es perfecto? Ni de coña. Pero nos hemos pasado una cantidad absurda de tiempo durante el verano planificando e implementando el regreso de CPCWiki. O sea, imagínate estar tomando algo al lado de la piscina y, en lugar de ligar con las chicas de la mesa de al lado, estar diseñando la configuración del servidor y los nodos de copia de seguridad (historia real). De hecho, me pasé la mayor parte de mi cumpleaños implementando cpcjs aquí
Bueno. Como ya he dicho antes, no soy ningún profesional de la informática ni nada por el estilo. Trabajo en marketing. Cuando decidí fundar la CPCWiki (primero como wiki, el foro vino después) no sabía casi nada sobre el tema. Es justamente este proyecto el que, a lo largo de los años, me ha enseñado UN MONTÓN de lo que sé hoy y, sin ironía, me ha ayudado también en mi trabajo profesional. No creo que sepa mucho, pero al menos estoy en algún punto al principio de la «rampa de la iluminación» en la curva de Dunning-Kruger, lo que me hace ser cauteloso y me obliga a aprender las cosas antes de actuar.
Tengo un rinconcito especial en mi corazón para SMF. Al fin y me cabo, pasé veinte años mimándolo. Pero es una solución arcaica.
Sin ir más lejos: SMF es, en esencia: «aquí tienes un montón de archivos PHP, hacen cosas juntos, siéntete libre de joderlo todo». Y, efectivamente, si la cagas con algo y no tienes una copia de seguridad a la que recurrir, la solución oficial es tirar el paquete de instalación encima de los archivos antiguos y revertir los cambios, perdiendo prácticamente todo en lo que habías trabajado. Y ese es el camino de actualización también, motivo por el cual con cada gran actualización perdíamos todas las personalizaciones y yo tenía que estar trabajando durante días en algo que debería llevar minutos.
Supongo que se ocuparán de ello con la versión 3, que a lo mejor llega para 2030… o no.
Discourse, por otro lado, te dice: «mira, rellena este app.yml, y luego siéntate a esperar o vete a dar un laaargo paseo mientras descargamos, configuramos e instalamos toda una pila de Compose. Puedes echar un vistazo, pero créenos, no quieres hacerlo».
Así que SMF es bastante más abierto y funciona bien nada más sacarlo de la caja, pero se rompe muy fácilmente (y algunas de las decisiones de diseño son cuestionables). Discourse es muy opaco en ese sentido, pero expone algunos puntos de entrada que te permiten hacer cosas sin romperlo.
No, no hubo manera, desactivé las suscripciones por completo. Al menos hasta que averigüe cómo implementarlo.
Bueno. Pero Atwood (y el otro chico, como se llame) sentían en gran medida que las páginas estáticas eran cosa de los años 90, y por eso tomó el otro camino con Discourse. Claro, una instalación de SMF se renderizará igual de bien en un PC de 2005, pero eso no dice mucho si tienes en cuenta la funcionalidad. Por ejemplo, he empezado este comentario en mi portátil y lo estoy continuando en mi teléfono, y volveré a mi portátil más tarde. Ah, y me parece recordar a gente quejándose de ASP.NET MVC en su día también
Se agradece mucho. Permíteme reiterar que los datos nunca salen del servidor (a ver, claro, Discourse hace algún ping por ahí y GA se ejecuta en segundo plano, pero no es que yo haga nada más con dichos datos). De hecho, me siento poco valorado porque nadie se me ha acercado para comprarme el conjunto de datos
Bien dicho. Pero realmente siento que Discourse es lo suficientemente ligero. Tengo dos pestañas abiertas ahora mismo y, con la CPU de mi portátil (otra vez) fijada en modo de ahorro de energía, Vivaldi me dice que consume precisamente el 0% de CPU y unos 350 MB. Eso está bastante bien, me parece a mí. Vale que la CPU es un Core Ultra 7 255HX, así que incluso funcionando a 2,4 GHz es bastante potente, pero…
Sí, la clave es «cualquier cosa que pueda funcionar».
No es que no esté de acuerdo contigo, la verdad, pero podríamos hacer funcionar esto como un BBS en ASCII y ver cuánta gente lo usaría
Esto tiene que ver con los niveles de confianza (Trust Levels). Aumenté un poco los límites para usuarios nuevos, pero creo que estaban bien antes también, salvo en casos raros:
Además, el límite de citas es una variable global, una decisión de diseño para evitar el caos de las respuestas anidadas. Lo he subido de 5 a 10 (porque a mí también me ha saltado el límite aquí )
En fin, una discusión realmente interesante. Gracias por tus amables palabras
Me gustaba SMF porque se sentía ligero y rápido incluso en una PC antigua (o en un equipo moderno con la configuración máxima de ahorro de energía).
Tras experimentar un poco con lo nuevo (redoble de tambores)… ¡ahora me gusta Discourse!
Una experiencia excelente en dispositivos móviles. Rápido y todo.
¡Un hurra para @Gryzor!
Llevo bastante tiempo echándole el ojo a Discourse, pero, claro, la migración era/es de difícil a imposible. ¡Me alegra saber que a la gente le está gustando!
Ahora que las API están disponibles, se podrían importar hilos del foro antiguo usando un agente de IA. Pero, siendo sincero, no tengo clara la utilidad. Aun así, imagino que no querrás seguir manteniendo dos foros y a mí me encantaría que todo ese material antiguo no se perdiera. Todo el conocimiento acumulado en el foro anterior… Así fue como aprendí (y recordé) muchísimas cosas sobre el Amstrad, además de descubrir otras que ni sabía que existían.
Por eso, mi objetivo principal con esto sería conservar todo ese conocimiento.
No, la verdad es que no sería posible; ¿qué pasa con los usuarios? ¿Los mensajes privados? Hay muchísimos detalles que no se pueden manejar a través de la API porque esta solo funciona a nivel superficial…
Mmm… Ya veo el problema y ahora mismo no tengo una buena solución. Le daré unas cuantas vueltas.
La idea sería dejar que un agente de IA simplemente lea el foro antiguo (que puede hacerlo ahora mismo, sin necesidad de API) y desde allí lo publique en el foro nuevo. Quizás solo contenido seleccionado…
Simplemente estoy buscando formas de conservar ese conocimiento. Si el foro antiguo desaparece, muere, etc., esa información se perderá para siempre.
Pero insisto, no se me ocurre una buena forma de conservarla adecuadamente en un archivo moderno. Déjame pensar y darle vueltas un poco más.
Sí, a eso me refería con «funciona en la superficie». Sería facilísimo rastrear el foro antiguo según ciertos criterios y crear nuevas publicaciones aquí mediante un agente. Sin embargo, lo primero que echarías en falta (y a partir de ahí todo se desmorona rápidamente) es que CADA publicación y hilo estarían bajo el mismo nombre de usuario, lo que causaría un caos.
) por la función de suscripciones. Lamentablemente, las suscripciones en Discourse están ligadas a Stripe. Y, aunque tengo pensado usar la función de suscripciones, no estará ligada a Stripe. Por desgracia, Stripe no se puede desactivar sin desactivar las suscripciones por completo, pero aún tengo que pensar cómo implementarlo. Al fin y al cabo, sigue siendo un trabajo en curso (WIP).
¡La comunidad CPC vuelve a tener su sitio web principal (en mi opinión) en línea! Podré leer a otros, hacer preguntas, mencionar mis proyectos en curso, etc.
Te mereces el reconocimiento.
Es una gran noticia.
parece que Discourse consume más CPU
(redoble de tambores)… ¡ahora me gusta Discourse!