carwyn

I really wish everyone was competing on efficiency. Most journeys require nowhere near the range capabilities of current EVs, instead carrying around excess weight when not required. Similarly on the acceleration side, other than showing off, why do we need cars that can do 0-60 in 2-3 seconds? Those kinds of g-forces are certainly not pleasant for passengers.

Different frameworks and language run-times move at different paces. It's very often the case that projects don't match their product pace and life-cycle to their toolset pace and life-cycle. "Standards" be it ABIs, APIs, data formats or markup languages all have different paces and life-cycles. Then there are the paces and life-cycles of the stacks underneath, the OS, the hardware, networks and data sources.

Then there's the security question. If this is a concern at all, ultimately the system may need to be air-gapped (e.g. like many systems depending on Windows XP are these days) to safely keep it running in lieu of fixes.

Another approach is common in the gaming scene with painstaking work on timing and bug-accurate emulation to keep old software running.

Ultimatley every system has a cost per annum, not a static capital cost. The end game being to maintain the hardware and "firewall" or update the software.

This is especially bad with anything based on Chromium/Electron and fractional scaling at the moment. The Ozone/Wayland back end is still a way off it seems.

High end tech procurement is more like your average market stall haggling than you might imagine. It tends to be the middle ground that's most stable.

The first of these certainly does happen, in this case though I suspect it may be a bit of both. When it comes to negotiation this will likely go both ways, the prestige and association of a project like CERN is worth something to large tech companies, as is being involved with the people and projects.

It's unlikely that they will be able to quickly or even ever move everything to new platforms, but with time there's a good chance they can move much of it. It will come down to the economics and time pressures of buy-in vs build-in.

This is perhaps the most poignant comment in the article:

"CERN has enjoyed special conditions for the use of Microsoft products for the last 20 years, by virtue of its status as an “academic institution”. However, recently, the company has decided to revoke CERN’s academic status, a measure that took effect at the end of the previous contract in March 2019, replaced by a new contract based on user numbers, increasing the license costs by more than a factor of ten."

I'm surprised no one has mentioned Open Collective yet:

https://opencollective.com/

They have an expense claim transparency system for each collective and a cool gifting system for larger organisations to allow their staff to donate to different collectives from the company pool.

How is having another vote, to establish a revised opinion based on new information and two long years of public debate and analysis of the original campaigns, undemocratic?

We could well be on path for a third general election in six years, a periodic vote to re-evaluate what we want as a country based on the current state of affairs.

Isn't being able to change your mind based on a changed context fundamental underpinning of a democratic system?

This is something that I've been intrigued about too. Most of the cli/text based creation tools out there focus on text based content as well. But, for many people myself included, the desire is really for a text based creation tool that focuses on image or diagram based output. Features like auto tiling (with priority) of images on a slide would be useful.

So many people end up writing what should be their presentation notes as their slide content. Personally I think you're better off with a holding image and move your content to the presenter notes section.

I've used revealjs.com and hovercraft [1] in the past but usually end up on GSuite Slides to throw things together quickly. Slides (like PowerPoint) can't do branching presentation paths though :(

[1] https://github.com/regebro/hovercraft

For contained web apps also see https://wavebox.io/

Homesteading the Noosphere by Eric Steven Raymond seems relevant in this discussion. Originally written 20 odd years ago.

"I examine the actual customs that regulate the ownership and control of open-source software."

http://www.catb.org/esr/writings/cathedral-bazaar/homesteadi...

As someone who interacts a lot with front line support for a fairly large organisation I find this balance interesting. Support channels are often a strange mix of FIFO with priority based queue jumping. I was at a talk by Kate Russell of BBC Click recently where she showed some stats on customer service based interactions heavily moving towards chat based interaction, obviously more and more backed by AI chat bots with human fallback. The next step on this path being voice chat also with bots.

Without the AI tier though scaling this is near impossible as you tend to a "most recent loudest" priority system, certainly if your support case to support rep ratio isn't balanced. Users also have to resort to repeating requests in a chat-only forgetful system.

This is why I ended up investigating hybrid sync/async interaction systems that cater better for not forgetting threads.

> Once you get used to the threading model of Zulip its hard to tolerate threading model like Slack which is really inefficient and time wasting.

This!

I got a bunch of our community to try out many of the different chat systems out there. Zulip was an interesting one as there were two points that really changed their perception of it as a platform:

1. When they were told there was a "Night Mode" - aesthetics are important! (something Slack arguably got right, IMHO beyond that it's just fancy IRC).

2. After around 5-10 minutes of playing around the penny drops as to why the stream and topic "zooming" is implemented in the way is it. Usually a "Holy Cow" moment.

Once you "get" it, going back to anything else feels like going back in time.

Topics aren't mandatory in Zulip. You can enable the "no topic" thread which makes them effectively optional.

Yes Slack has threads, but they aren't implemented in a way that's conducive to ad-hoc interaction over longer periods of time.

This is exactly the issue with the style of threads used in Slack, Teams, Hangouts Chat etc. Their useful half-life tends to them being forgotten quickly.

It's more real-time capable than classical forum software meaning you can use it as a channelized chat system.

Yes, Discord, IRC, Riot/Matrix and Zulip for example make this very clear. Some of the others have it but not obvious.

One thing that Spectrum has that's similar to forum software is a reputation system. Others have admin/moderator status but nothing further.

Discord's mass concurrent voice chat is very impressive, but then they did hone this in 64 man WoW raids and the like. The new screen sharing they added a while back is nice too. Interesting implementation (you can pick which of the nine to watch at any given time).

Video chat is the latest I've been looking into with Zoom starting to stand out above Hangouts and Skype, especially for one to very many and multiple speakers in turn type arrangements. Zulip can hook into Jitsi and Hangouts.

I couldn't for the life of me understand how many people I spoke to didn't see the problem that lack of threading and async catch-up posed to linear chat systems as Slack gained in popularity. to me it felt like a forgetful, prettified IRC with awkward sign-up.

Personally I find Zulip to have the nicest implementation of "topic zooming" as it still allows for a global linear view of all activity. Spectrum feels a bit more "channelized" and a bit white-space heavy but prettier.

Zulip's mobile client has come a long way in recent months too.

The hardest part though was trying to convince the community to migrate away from other social platforms. Meetup was (still is) driving me mad with their forums/discussions features which are woeful.

On the purely async focused side the two standouts where Discourse (https://www.discourse.org/) and Flarum (https://flarum.org/).

I spent a fair bit of time trying out many of the different chat systems out there for our tech community. In particular I looking for solutions that could do a half decent job of combining synchronous as well as asynchronous communication. The main benefit of implementations that manage to pull this off is being able to handle real-time chat but also make it easier to catch up with the conversation history if you've been away from the conversation for a while. Other criteria I was looking for were sensible threading, mobile friendly, persistence of history and private channels. Integration with voice or video chat was a bonus.

Amongst others I tried: Mattermost, Rocket.chat, IRC(Cloud), Gitter, Discord, Slack, MS Teams, Twist, Hangouts Chat.

Two stood out, both open source (Spectrum wasn't when I started looking):

Spectrum: https://spectrum.chat/

Zulip: https://zulipchat.com/

These two along with Twist (proprietary) manage to deal with the threading and hybrid sync/async. Both the above also have exceptionally helpful people behind them.

The other special mention goes to Matrix (https://matrix.org/) and Riot (https://riot.im/) as their persistence syncing and federation work is impressive. Their threading and hence async story isn't as well developed yet though (https://github.com/vector-im/riot-web/issues/2349).

When it's ready. If there's one thing Red Hat have been pretty good at it's being conservative and not worrying too much about schedule slips.

This pump storage facility has been running in North Wales since 1984:

http://electricmountain.co.uk/Dinorwig-Power-Station

It has three main roles on the national grid:

1. Near instant response for peak demand fluctuations (e.g. half time during major sports events). 2. Bootstrapping generator for rebooting the national grid should we ever need to. 3. Grid frequency regulation (keeping that AC at 50Hz)

There are a number of projects in progress to look at consumer side Demand Side Regulation (DSR) to provide the latter two grid services without having to carve out mountains or build massive battery farm like Tesla.

Often the addiction comes after the homelessness as a mechanism to combat boredom and cold.

Mental illness, financial circumstance and relationship breakdowns (family or spouse) are indeed common initial causes. Especially PTSD in veterans.

Generics are very unlikely to happen before Go 2

https://dave.cheney.net/2017/07/22/should-go-2-0-support-gen...

There is this https://blog.golang.org/toward-go2

It's been perfectly possible to do real work on a Chromebook using web IDEs, Crouton or tools like Termux for some time now. Similarly, Linux on laptops has been perfectly viable for many many years. I ditched my MacOS experiment around a decade ago after getting fed up of the terrible package management story. Fink and macports were trying their best fair play. Better with brew these days but still not in the same realm as the native Linux package tools and repositories. Similarly if you're using containers the native story is just smoother.

For certain types of organisations, especially those with dealing with more in-house projects Phabricator is really worth a look:

https://www.phacility.com/phabricator/

Surely the most effective way of improving shipping efficiency is to stop shipping as much? The principal of locality can be applied to far more than memory architectures.

Surely W3C and WHATWG would periodically branch and freeze a version of living standard? Possibly defining some elements as optional or extensions much like OpenGL or Vulkan? It seems crazy that they proposal introduced changes to what was already established common practice.

Create your own. That's what we did with http://northwales.tech/