"Out of the frying pan, into the fire"

Google's first quarter 2023 report shows they made massive profits off vast revenue due to advertising.

It is about control though. The thing that caught my eye is that they're saying that only "approved" browsers will be able to access these WEI sites. So what does that mean for crawlers/scrapers? That the big tech companies on the approval board will be able to lock potential competitors out of accessing the web - new browsers, search engines, etc. but much more importantly... Machine Learning.

Google's biggest fear right now is that ML systems will completely eliminate most people's reason to use Google's search, and therefore their main source of revenue will plummet. And they're right to be scared, it's already starting to happen and it's showing us very quickly just how bad Google's search results are.

So this seems to me like an attempt to control things from that side. It's essentially the "big boys" trying to consolidate and firm-up their hold in the industry and not let newcomers rival them, as with ML the barrier to entry has never been lower.

I personally found Fedora to be rock solid, and along with Ubuntu provided the best hardware support out of the box on all my computers - though it's been a couple of years since I used it. I did end up on Ubuntu non-LTS in the end as I now run Ubuntu LTS on my servers and find having the same systems to be beneficial (from a knowledge perspective).

I hear they have improved performance now though

It's still not great. Better, but still slow enough to make you question whether you've actually launched the app or not.

I don't think consolidation, compromise, and coming together in one common direction are the hallmarks of open source at all!

Filesystems, service management/startup, audio output, desktop environment, package formats/management/distribution, programming languages, shell, and so on, and so on - all have many, many options.

Open source is, if nothing else, fractured.. it's about choice, flexibility, and re-inventing the wheel not because it really needs to be re-invented, but because it's fun to do so and useful to have something that perfectly fits your requirements.

We've made room for many package formats for decades, and will continue to do so for decades to come I'm sure.

It does feel like there's been a shift, especially in organisations that use the work of others for their own benefit (e.g. open source, community produced content, etc). It seems like there's been a real move to have their cake and eat it.

Oracle has just made an aggressive move with regards to Java licensing too, they're now charging as much as $15/month/employee to use their Java runtime on the desktop/server. Their FAQ even points you to OpenJDK if you don't want to pay, which is strange - it makes me think the relationship between Oracle and the OpenJDK will be ending sometime in the not-so-distant future. There are several Java projects I've done where that would just become non-viable as it was a project for a single department in a large company.

Software developers are one of the most altruistic groups of people - it's amazing just how much time and effort they put into things that they get no financial return on, only the love of actually doing it. And people that dedicate their time and effort to online communities, education, and so on are equally amazing.

But I think it's time to stop being so naive and realise that many large corporate entities are abusing this relationship for their own gain.

Don't roll your own if you can help it, just use a distribution dedicated for use as a thin client. I was co-incidentally just looking into this last week and came across ThinStation which looks really good. There are other distro's too, search for "linux thin client".

Are there any good alternatives?

We've started using Jitsi for video/screen-sharing and that's going well so far - but it's based very much around the "corporate meeting" concept, rather than "playing D&D with mates" or "online gaming with people".

Mumble is decent enough for voice comms, but of course lacks video, which for my friend group is a deal-breaker. While the audio quality is noticably better most of the time, its noise suppression is not as good as Discord. It does have text chat, but lacks the utility of Discord's chat - which we use in D&D for sharing information, images, note-taking, etc.

Things do game tracking/voice like Steam, Xbox Live, PSN, etc. but then each only supports their own platforms and services - whereas Discord is common to all.

I think what DIscord does well is bring together a few really established, tried and tested technologies, under one roof and integrates them seamlessly. There is definitely value in that, and I would be really interested in an open source/self-hosted equivalent.

My main concerns with Discord are:

1. They inevitably ramp up income earning opportunities and therefore eventually compromise the system.
2. It can't be catalogued/searched easily.
3. It seems like a near-perfect platform for harvesting data for ML (and the platform has some traction with the ML community already).

Red Hat saying that argument in-particular shows they've pivoted their philosophy significantly, it's a seemingly subtle change but is huge - presumably due to the IBM acquisition, but maybe due to the pressures in the market right now.

It's the classic argument against FOSS, which Red Hat themselves have argued against for decades and as an organisation proved that you can build a viable business on the back of FOSS whilst also contributing to it, and that there was indirect value in having others use your work. Only time will tell, but the stage is set for Red Hat to cultivate a different relationship with FOSS and move more into proprietary code.

I just have a static page that I randomly change - you can see mine here. In this case I was testing the idea of having text within an SVG for better scaling from mobile to desktop, and also I'm loving orange and purple at the moment for some reason! Oh, and I was testing automated deployments from CI/CD, so I always use my own base domain with those first tests!

I think the most interesting thing out of the Red Hat/CentOS/downstream thing was that Red Hat used the absolute classic argument against FOSS - "they're getting value out of this without contributing back". The argument that Red Hat themselves spent so long fighting against and building their company around proving that argument wrong.

I think it shows a shift in mind-set, perhaps born from the IBM purchase, perhaps as they start to feel the squeeze, and that they no longer fully believe in FOSS.

But it's early days, only time will tell - certainly there seems to be a fair few shifts going on at the moment though!

As always, it depends! I'm a big fan of "the right tool for the job" and I work in many languages/platforms as the need arises.

But for my "default" where I'm building up the largest codebase, I've gone for the following:

• TypeScript
  • Strongly-typed (ish) which makes for a nice developer experience
  • Makes refactoring much easier/less error-prone.
  • Runs on back-end (node) and front-end, so only one language, tooling, codebase, etc. for both.
• SvelteKit
  • Svelte as a front-end reactive framework is so nice and intuative to use, definite the best there is around atm.
  • It's hybrid SSR/CSR is amazing, so nice to use.
  • As the back-end it's "OK", needs a lot more work IMO, but I do like it for a lot of things - and can not use it where necessary.
• Socket.IO
  • For any real-time/stream based communication I use this over plain web sockets as it adds so much and is so easy to use.
• PostgreSQL
  • Really solid database that I love more and more the more I use it (and I've used it a lot, for a very long time now!)
• Docker
  • Easy to use container management system.
  • Everything is reproducible, which is great for development/testing/bug-fixing/and disasters.
  • Single method to manage all services on all servers, regardless of how they're implemented.
• Traefik
  • Reverse proxy that can be set to auto-configure based on configuration data in my docker compose files.
  • Automatically configuring takes a pain point out of deploying (and allows me to fully automate deployment).
  • Really fast, nice dashboard, lots of useful middleware.
• Ubuntu
  • LTS releases keep things reliable.
  • Commercial support available if required.
  • Enough name recognition that when asked by clients, this reassures them.

From a personal perspective, I absolutely agree - I only check my email when I'm specifically expecting something, which is rarely. But at work emails are still incredibly important.

Are there any protocols/services designed specifically for one time codes? Receipts? I think something that's dedicated to those kinds of tasks would be great from an ease-of-use perspective - no more messing about waiting for delivery, searching through hordes of emails, checking spam folder, etc.

Another problem we have is the rise of oauth - the core idea is great, but the reality is that it ties a lot of people to these Big Tech services.

Often the question marked as a duplicate isn't a duplicate, just the person marking it as such didn't spend the time to properly understand the question and realise how it differs. I also see lots of answers to questions mis-understanding the question or trying to force the person asking down their own particular preference, and get tons of votes whilst doing it.

Don't get me wrong, some questions are definitely useful - and some go above-and-beyond - but on average the quality isn't great these days and hasn't been for a while.

Containers can be based on operating systems that are different to your computer.

Containers utilise the host's kernel - which is why there needs to be some hoops to run Linux container on Windows (VM/WSL).

That's one of the most key differences between VMs and containers. VMs virtualise all the hardware, so you can have a totally different guest and host operating systems; whereas because a container is using the host kernel, it must use the same kind of operating system and accesses the host's hardware through the kernel.

The big advantage of that approach, over VMs, is that containers are much more lightweight and performant because they don't have a virtual kernel/hardware/etc. I find its best to think of them as a process wrapper, kind of like chroot for a specific application - you're just giving the application you're running a box to run in - but the host OS is still doing the heavy lifting.

I think all the flexibility and distributed nature of open source is simultaneously it's greatest strength and greatest weakness. It allows us to do so much, to tailor it to our specific needs, to remix and share, and to grow communities around common goals. But at the same time, those communities so rarely come together to agree on standards, we reinvent the wheel over and over, and so we can flounder vs big corporations with more clearly defined leadership. Flexibility and options seems to lead to an inability to compromise.

But also I think open source and standards have become a battleground for Big Tech, with different mega-corps looking to capitalise on their ideas and hinder those of their competitors. Microsoft trying to push TypeScript into the ECMCA Script standard, Google trying to force AMP down our throats, Apple saying fuck-off to web standards/applications, the whole Snaps/Flatpak/Appimage thing, WebAssembley not having access to the DOM, etc.

I think one of the great things that open source does is that it effectively puts the code in people's hands and it's up to them to get value out of that however they can. But so often now it's these mega-corps that can garner the most value out of them - they can best market their offers, collect the most data to drive the software, bring to bare the most compute power, buy up and kill any threats to their business, and ultimately tip the balance very firmly in their favour.

Open source software needs contributors, without them it's nothing - sure you can fork the codebase, but can you fork the team?

Most people do the work because they love it - it's not even because they particularly want to use the software they create, it's the act of creating it that is fun and engaging for them. But I wonder if perhaps we're starting to cross a threshold where more restrictive licenses could start to gain more popularity - to bring back some semblance of balance between the relationship of community contributors and mega-corps.

Tim Berners-Lee would be interesting I think, given the direction he's gone into personal ownership/control of data.

I use it for basic 2D animation - overlays for videos (captions, title sequences, etc.) and animated diagrams - it works really well when you get used to it (mastering the curves editor is essential!). If you're going to composite what you do onto video outside of Blender (I use Resolve) you need to export as an image sequence in a format that supports transparency (e.g. png).

For more complex 2D work, Marco Bucci has an interesting three-part series here (the third part goes over animation specifically).

Containerised everything is the future of computing and I think we'll look back on how we do things currently with horror!

But yes, I am slowly starting to use more contained desktop applications. Server-wise, everything I deploy is now in containers.

He's pushing for a decentralised web, he's specifically focussed on personally owned data through his Solid project. But it feels like maybe this month or so could be a tipping-point, so it would be great to get his input and/or for him to see how we all work away at it!

This is a truly excellent pair of articles, brilliantly written.

Explains the problem, show the solution iterating step by step so we start to build an intuition about it, and goes as far as most people actually need for their applications.

This is really interesting, I've never heard of such an approach before; clearly I need to spend more time reading up on testing methodologies. Thank you!

In the original XCOM my brother and I didn't realise you needed to collect and research everything. We thought it was like a horde-survival game, however it could infact be completed. Learning this years after starting to play was one of my best gaming experiences - I came back to my parents for the weekend just to blow my brother's mind!

We've got some Brother laser printers at work and they've been great. We get third-party toner from a local company for peanuts too, as well as sending them the old cartridges to reuse/recycle. If I ever need a printer at home, this is the route I'll go!

EDIT: Also, checkout company closing auctions (there's a few around again!) and you can pick-up some decent office stuff including printers for cheap!

The issues with LLM's for coding are numerous - they don't produce good results in my experience, there's plenty of articles on their flaws.

But.. they do highlight something very important that I think we as developers have been guilty of for decades.. a large chunk of what we do is busy work; the model definitions, the api to wrap the model, the endpoint to expose the model, the client to connect to the endpoint, the ui that links to the client, the server-side validation, the client-side validation, etc. On and on.. so much of it is just busy work. No wonder LLM's can offer up solutions to these things so easily - we've all been re-inventing the wheel over and over and over again.

Busy work is the worst and it played a big part in why I took a decade-long break from professional software development. But now I'm back running my own business and I'm spending significant time reducing busy work - for profit but also for my own personal enjoyment of doing the work.

I have two primary high-level goals:

1. Maximise reuse - As much as possible should be re-usable both within and between projects.
2. Minimise definition - I should only use the minimum definition possible to provide the desired solution.

When you look at projects with these in mind, you realise that so many "fundamentals" of software development are terrible and inherently lead to busy work.

I'll give a simple example.. let's say I have the following definition for a model of a simple blog:

User:
  id: int generate primary-key
  name: string

Post:
  id: int generate primary-key
  user_id: int foreign-key(User.id)
  title: string
  body: string

Seems fairly straight-forward, we've all done this before - it can be in SQL, prisma, etc. But there's some fundamental flaws right here:

1. We've tightly coupled Post to User through the user_id field. That means Post is instantly far less reusable.
2. We've forced an id scheme that might not be appropriate for different solutions - for example a blogging site with millions of bloggers with a distributed database backend may prefer bigint or even some form of UUID.
3. This isn't true for everything, but is for things like SQL, Prisma, etc. - we've defined the model in a data-definition language that doesn't support many reusability features like importing, extending, mixins, overriding, etc.
4. We're going to have to define this model again in multiple places.. our API that wraps the database, any clients that consume that API, any endpoints that serve that API up, in the UI, the validation, and so on.

Now this is just a really simple, almost superficial example - but even then it highlights these problems.

So I'm working on a "pattern" to help solve these kinds of problems, but with a reference implementation in TypeScript. Let's look at the same example above in my reference implementation:

export const user = new Entity({
    name: "User",
    fields: [
        new NameField(),
    ],
});

export const post = new Entity({
    name: "Post",
    fields: [
        new NameField("title", { maxLength: 100 }),
        new TextField("body"),
    ],
});

export const userPosts = new ContentCreator({
    name: "UserPosts",
    author: user,
    content: post,
});

export const blogSchema = new Schema({
    relationships: [
        userPosts,
    ],
});

So there's several things to note:

1. Entities are defined in isolation without coupling to each other.
2. We have sane defaults, no need to specify an id field for each entity (though you can).
3. You can't see it here because of the above, but there are abstract id field definitions: IDField and AutoIDField. It's the specific implementation of this schema where you specify the type of ID you want to use, e.g. IntField, BigIntField, UUIDField, etc.
4. Relationships are defined separately and used to link together entities.
5. Relationships can bestow meaning - the ContentCreator relationship just extends OneToMany, but adds meta-data from which we can infer things in our UI, authorization, etc.
6. Fields can be extended to provide meaning and to abstract implementations - for example the NameField extends TextField, but adds meta-data so we know it's the name of this entity, and that it's unique, so we can therefore have UI that uses that for links to this entity, or use it for a slug, etc.
7. Everything is a separately exported variable which can be imported into any project, extended, overridden, mixed in, etc.
8. When defining the relationship we sane defaults are used so we don't need to explicitly define the entity fields we're using to make the link, though we can if we want.
9. We don't need to explicitly add both our entities and relationships to our schema (though we can) as we can infer the entities from the relationships.

There is another layer beyond this, which is where you define an Application which then lets you specify code generation components that to do all the busy work for you, settings like the ID scheme you want to use, etc.

It's early days, I'm still refining things, and there is a ton of work yet to do - but I am now using it in anger on commercial projects and it's saving me time - generating types/interfaces/classes, database definitions, api's, end points, ui components, etc.

But it's less about this specific implementation and more about the core idea - can we maximise reuse and minimise what we need to define for a given solution?

There's so many things that come off the back of it - so much config that isn't reusable (e.g. docker compose files), so many things that can be automatically determined based on data (e.g. database optimisations), so many things that can be abstracted (e.g. deployment/scaling strategies).

So much busy work that needs to be eliminated, allowing us to give LLM's a run for their money!

Same - for Windows it's by far and away the best PDF reader for me. It's shocking how far down the bloat rabbit hole Adobe Reader has gone!

Definitely give Ruthless a go, I love it.. reminds me of early game ARPG's on higher difficulties. Positioning really matters, you have to adapt based on what you get. It seems to have been the proving ground for PoE2's new tempo.

If I’m okay with the software (not just trying it out) am I missing out by not using dockers?

No, I think in your use case you're good. A lot of the key features of containers, such as immutability, reproduceability, scaling, portability, etc. don't really apply to your use case.

If you reach a point where you find you want a stand-alone linux server, or an auto-reconfiguring reverse proxy to map domains to your services, or something like that - then it starts to have some additional benefit and I'd recommend it.

In fact, using native builds of this software on Windows is probably much more performant.

I chose Ubuntu for my desktop/laptop because I chose Ubuntu for our servers. While we now have the servers setup such that we hardly touch them directly, I've found it to be incredibly valuable to be using the same technologies, tools, and processes daily on desktop as I need on our servers.

It boggles my mind how many organisations I've worked for that almost exclusively develop for Linux deployment use Windows as their primary desktop environment. It causes nothing but trouble. We've got Windows if we need it, I'm a big proponent of the best tool for the job - and what the company paying wants! - but Linux is our primary desktop environment.

Yes, I love it! Really it's the MacOS-like "Expose" feature that I find to be essential.

I would advise against using workspaces though, I find those actually sort of go against the core idea of it IMO. There are a few things I'd really like added to it, but for the most-part when you get into it it's great.

My main desktop I have 4 monitors (I know, but once you start a monitor habit it's really hard to not push it to the limit - this is only the beginning!) It roughly breaks down into:

1. Primary work (usually a full-screen editor)
2. Terminals (different windows, some for the project, some monitoring)
3. Browsers - documentation, various services, my own code output
4. Communication - signal, discord, what's app (ugh), etc.

The key, literally, is you just press the Super key and boom, you can see everything and if you want to interact with something it's all available in just one click or a few of key presses away.

On my laptop with just one screen, I find it equally invaluable, and is actually where I started to use it the most - once again, just one press of Super and I can see all the applications I have open and quickly select one or launch something.

It's replaced Alt + Tab for me - and I know they've made that better, and added Super + Tab, but none of them are as good as just pressing Super.

The things I'd really love added to it are:

• Better tiling (including quarter tiling). It's a sad state of affairs when Windows has far better tiling than Gnome.
• Super then Search, I'd like it to filter the windows it's showing and shrink/hide the others, along with a simple way to choose one using the keyboard.
• Rather than having an icon for each window, I also want the tooltip information to always be shown (e.g. vs code project) and for standard apps to expose better information for that (e.g. Gnome Terminal to expose its prompt/pwd) and/or have a specific mechanism by which apps could communicate.
• Adding Quicksilver-like functionality to the launcher/search would be amazing. e.g.
  • Super
  • Sp... (auto-populates Spotify)
  • Tab
  • P... (auto-populates Play/Pause)
  • Return
• Session restoration - it just doesn't work at the moment for some reason. Some apps do, some don't. Some go to their correct position/size, some don't.

I'm new to it too, I've known about its existence but have been thinking about adding support for it to a project I'm starting soon - really to learn more about it (I tend to learn best by doing!)

It's goal is for each of us to have personal ownership of all our data online, and full control over who can access what. That's certainly something I can get behind! You do this by creating a "pod", which is essentially a database of all your data (I think organised into groups, e.g. each organisation can have their own group of data), which you can self-host if you like, along with the ability to control access.

It's current impact I would say is near zero. But TBL is a person with a reasonable amount of pull, and he's setup his own company providing commercial services (presumably, consulting). My guess is they're dealing with governments and mega-corps - there seems to be very little effort pushing it to "the masses" (i.e. application developers).

The theory sounds interesting but the practicalities of it seem to offer a lot of challenges, so I think the best way to get a real sense of whether it has legs or not is to build something!

It'll be interesting to see if this runs long enough to overlap with the Starfield launch - I could see them getting an insane spike in subscribers then anyway, but this would likely seal the deal for many more.

Assume nothing! Test every little assumption and you'll find the problem. Some things to get you started:

• Does the "app" domain resolve to the app container's IP from within the nginx container?
• Can you proxy_pass to the host:port directly rather than using an upstream definition? If not, what about IP:port?
• Can you connect to the app container from outside (if exposed)? What about from inside the nginx container? What about inside the app container?
• Is the http(s) connection to the server (demo.example.com) actually going to your nginx instance? Shut it down and see if it changes.
• If it works locally on 80, can you get it to work on the VPS on 80?
• Are you using the exact same docker-compose.yaml file for this as locally? If not, what's different?
• Are you building the image? If so, are you incrementing the version number of the build so it gets updated?
• Is there a firewall running on the host OS? If so, is it somehow interfering? Disable it and see.

While not a direct solution to your problem, I no longer manually configure my reverse proxies at all now and use auto-configuring ones instead. The nginx-proxy image is great, along with it's ACME companion image for automatic SSL cert generation with certbot - you'll be up and running in under 30 mins. I used that for a long time and it was great.

I've since moved to using Traefik as it's more flexible and offers more features, but it's a bit more involved to configure (simple, but the additional flexibility means everything requires more config).

That way you just bring up your container and the reverse proxy pulls meta-data from it (e.g. host to map/certbot email) and off it goes.

I was using file merging, but one issue I found was that arrays don't get merged - and since switching to use Traefik (which is great) there are a lot of arrays in the config! And I've since started using labels for my own tooling too.

Ahh! I didn't see that! Thanks.

That makes sense, thank you. Yes, it's specifically "test quality" I'm looking to measure, as 100% coverage is effectively meaningless if the tests are poor.

I use coverage tools like nyc/c8, but I can easily get 100% coverage on buggy, exploitable, and unstable code. You can have two projects, both with 100% coverage, and one be a shit show and the other be rock solid - so I was wondering if there's a way to measure quality of tests, or to identify code that really needs extra attention (despite being 100%). Mutation testing has been suggested and that's really interesting, I'm going to give it a go tomorrow and see what it throws up!

I did not know about the shopt command! Very interesting, thank you.

However, while your description refers to a GitHub Gist, there doesn't seem to be a link to it.

I was recently helping someone working on a mini-project to do a bit of parsing of docker compose files, when I discovered that the docker compose spec is published as JSON Schema here.

I converted that into TypeScript types using JSON Schema to TypeScript. So I can create docker compose config in code and then just export it as yaml - I have a build/deploy script that does this at the end.

But now the great thing is that I can export/import that config, share it between projects, extend configs, mix-in, and so on. I've just started doing it and it's been really nice so far, when I get a chance and it's stabilised a bit I'm going to tidy it up and share it. But there's not much I've added beyond the above at the moment (just some bits to mix-in arrays, which was what set me off on this whole thing!)

This is surely AI generated, but even so it's still awful and a decade or more behind the curve of what I'd expect from AI blog spam!