Please wait...
John Conway, the mathematician famous for creating "Conway's Game Of Life", has died.
Does that mean Life games are now all just empty squares?
Mon Sep 16 2019 06:17:23 EDT from fleeb @ Uncensored
You don't really need to do this with containers, but containers do make it significantly easier for most applications.
We write proprietary code for Linux and Windows that must work on 10-year-old versions of the operating system. We only distribute binaries, no sources.
And we can't use containers, as they isolate software too much for our needs.
Because of what we want to accomplish, we *can't* 'own the machine'. But, we don't want the hassle of wondering what fucking dependency broke our shit, so we build our own dependencies (to 10-year-old specs), and engineer everything to only depend on the kernel, to the degree that's possible.
We do, however, want to own our own sources. We're a closed-source shop.
We're very far ahead of any competitors in our space. If we opened the sources, we would significantly risk losing that edge.
I would point out, though, that open-source software also conflicts with each other... it happens quite a lot. It falls on package maintainers for the distribution to curate everything to ensure they work together. What you see is a bit of an illusion caused by this curation process. Eventually, some breaking piece of software is either brought to heel, or causes changes in dependant software to help make everything work again, but if you think open-source software never breaks and everything is peaches and funshine with cookies and happy squeaky ponies, you haven't read through a lot of the tickets those guys are solving.
As a closed-source developer, I find it frustrating that I can't be part of that process. I recognize that I risk 'poisoning' open-source with certain contributions if I'm not careful. I can't build features for open-source very easily... I'd have to do it on my own time, and would therefore not be of particularly good quality (since I've already spent much of my day working on closed-source stuff to earn my living). I can contribute tiny bug fixes, but that's about it.
So, I don't have a lot of influence on open-source development.
This is exactly what we are doing aswell. Statically link all the userspace libs needed to only depend on the kernel elf loader. But things get pretty tricky with GPL libs, thats why we usually provide the *.o files of our compiled source (don't ask me why that's something our legal department tells us to do to not violate the GPL). BTW, I recently found a quite helpful repo to build some common needed userspace libs: https://github.com/nwrkbiz/static-build
I noticed that the Debian package for Citadel was unmaintained. Citadel is new to me, I've been getting familiar. I might consider picking it up.
I believe the previous (or existing) maintainer was doing it reluctantly.
I'd be surprised if the new explicitly anti-SJW CoC doesn't arouse some rage among package maintainers. "Fuck these Nazis!"
2020-09-26 07:18 from nonservator
Subject: Re: speaking of the Debian package
I'd be surprised if the new explicitly anti-SJW CoC doesn't arouse
some rage among package maintainers. "Fuck these Nazis!"
What's this? All I see is https://www.debian.org/code_of_conduct
If "assume good faith" is explicitly anti-SJW (and in the extreme cases, I believe it can be) but I suspect you meant something else
2020-09-26 07:18 from nonservator
Subject: Re: speaking of the Debian package
I'd be surprised if the new explicitly anti-SJW CoC doesn't arouse
some rage among package maintainers. "Fuck these Nazis!"
Wait, is there an anti-SJW code of conduct in Debian????
We are talking about the same Debian that used to sponsor a feminist debian program, aren't we????
The debian CoC looks totally reasonable. I am actually very pleasantly surprised that it is merely a page full of text telling people to be courteous and respectful to each other.
I suspect that nonservator is actually talking about the Citadel project's code of conduct, which begins with an anti-SJW statement and concludes with "don't be a jerk."
2020-09-28 10:46 from IGnatius T Foobar
Subject: Re: speaking of the Debian package
The debian CoC looks totally reasonable. I am actually very
pleasantly surprised that it is merely a page full of text telling
people to be courteous and respectful to each other.
I suspect that nonservator is actually talking about the Citadel
project's code of conduct, which begins with an anti-SJW statement and
concludes with "don't be a jerk."
Ok, that would make more sense then.
I love the citadel's code of conduct.
On the other hand, I am not a fan of the website upgrade. It requires JS to work properly it seems.
On the other hand, I am not a fan of the website upgrade. It requires
JS to work properly it seems.
that's just a step towards the modern developmet best-practice, which is moving toward serving static content to a browser which queries for dynamic content directly via either RESTful apis or WebSockets, and performs all HTML rendering as DOM manipulations on the client-side from JS.
the "websites should function without JS enabled" battle was fought, and lost, more than a decade ago.
True. I know where darknetuser is coming from though; he hangs out in circles
where javascript sites are not seen as trustworthy. For those people we have
... the text client :)
www.citadel.org is using the "w3css" framework, which helps create sites that look good on lots of different devices, but does not require any big components like JQuery to do so. This was a migration away from DokuWiki, which we were using for over a decade, and it was getting difficult to maintain.
The new site is done all in static HTML with a couple of server-side includes to insert the header and footer on each page. It's delightfully easy to maintain.
webcit-ng is also being built (at its current glacial pace) using the W3CSS framework, and in the best-practice described above, as a static site that makes queries to a REST API for dynamic content that it renders on the client side.
I think the current battle is "web sites should function without cross-site cookies enabled". I see good progress in this battle, actually. In a couple of places -- for example, third-party comment sections -- where you previously could not log in to the comment plugin without cross-site cookies, clicking on some element of the comment section now opens a little external window that handles the redirect chain.
www.citadel.org is using the "w3css" framework, which helps create sites that look good on lots of different devices, but does not require any big components like JQuery to do so. This was a migration away from DokuWiki, which we were using for over a decade, and it was getting difficult to maintain.
The new site is done all in static HTML with a couple of server-side includes to insert the header and footer on each page. It's delightfully easy to maintain.
webcit-ng is also being built (at its current glacial pace) using the W3CSS framework, and in the best-practice described above, as a static site that makes queries to a REST API for dynamic content that it renders on the client side.
I think the current battle is "web sites should function without cross-site cookies enabled". I see good progress in this battle, actually. In a couple of places -- for example, third-party comment sections -- where you previously could not log in to the comment plugin without cross-site cookies, clicking on some element of the comment section now opens a little external window that handles the redirect chain.
Looks like Selenium/WebDriver is becoming obsolete:
https://github.com/microsoft/playwright
Yep, it's from those guys. But the devs are the same team formerly employed by Google who built Puppeteer
It is likely that I will be digging into Playwright in great depth in the coming weeks, for work. We'll be building client stubs for the wire protocol for a language that is not yet supported (unless priorities change...) so, I may have more to say later.
Tell me about that "await" keyword. Does it do what I think it does? From the code snippets it looks like you can use that to write browser-side javascript code iteratively, instead of putting a handler inside a block of an XHR call. Is that what it does?
Sadly y Paywright project got cancelled... we actually got as far as consulting with the MS open source devs on an estimate, and it was looking like a 2-developer, 3-month sort of project... too much. It would have been "fun", but... I guess I dodged a bullet.
"await" is a heavy dose of syntactic sugar to allow you to write event-loop callbacks in a style that looks like a traditional sequence of method calls instead of deeply nested Promise objects. It actually compiles down to the same thing: nested Promise objects.
If you're targeting browsers that don't support it, you can use a transpiler to go from a more recent JavaScript version (or TypeScript) down to a previous JS version.
"await" sounds like exactly what I want (me and probably everyone else) for writing dynamic web apps. What other toolkits provide it?
In the prehistoric times I used Prototype, and then briefly experimented with JQuery before discovering the "you might not need JQuery" trend. Now I just write raw XHR calls because it's been fully supported by every browser for a long time now.
But, the idea of being able to structure a program so that things appear iterative would be a big plus. I'd love to get out of the design pattern of XHR calls with nested or external functions to handle the server response, which can go several levels deep in a complex program.
`await` is part of the core javascript language, these days. It was introduced in ECMAScript 8, I think. It's supported by the latest versions of all major browsers except IE. If you want to target IE (or other old stuff), you will need to use a transpiler to compile your modern JS down to an earlier equivalent that uses Promises.
We use a few different JS frameworks here. For our customer-facing site, we use React (which is quite popular lately.) For our backend stuff, the approach is a little more Web 1.0, so we use a mix of server-generated HTML with hodgepodge of small JS[browser-side frameworks that don't really want to own your whole approach, ie, support more iterative adoption. (This app doesn't do a lot in JavaScript.)
else) for writing dynamic web apps. What other toolkits provide it?
basically anything that returns a Promise works with await.
Aah, ok I see that for the typical dynamic web page use case, "await" is used
with "fetch", is that correct?
response = await fetch(url);
text = await response.text();
// then do something with text
If that does what I think it does, it's a lot less work than setting up an entire XHR and a callback.
response = await fetch(url);
text = await response.text();
// then do something with text
If that does what I think it does, it's a lot less work than setting up an entire XHR and a callback.