I guess I could go with IDE .. but the real winner has been github copilot, just reading my mind and having so much code ready for autocomplete as I type. It seems like half of my coding is hitting tab lately.

Don't get me wrong, it makes mistakes, I often have to edit, or undo .. but that's often balanced by times that it suggests something before my brain had even gotten to the next step.

Brave new world ...

This week on "year of Linux on the desktop": online services like MMO games and streaming video services make a fortune by running Linux free of charge on their own servers but won't properly support paying customers who run it on their desktops.

What matters is what is normal for that employment relationship. Unless you've been working for the same employer for hundreds of years, your argument is irrelevant in law.

Under our employment laws, an employer can't unilaterally alter the fundamental nature of the employment relationship, which takes into account custom and practice. Of course they can decide the work needs to be done a different way, and that might result in some of their current employees becoming redundant, but they still have to provide the usual support for affected employees in that case. They don't just get to make a big change that effectively forces people who lose out as a result to quit without providing proper compensation.

TBH, it's a little hard to follow the back and forth of the comments earlier in this thread, so maybe we're talking at cross-purposes here, but that's the point I'm trying to make. It's not just about whether WFH is explicitly written into someone's contract at this point.

Because employment contracts here can and often do have implied terms based on custom and practice, those terms can be enforceable, and attempts to unilaterally change them in significant ways can constitute a breach of contract.

Arguing that WFH is just a COVID thing if it's been the norm at a company for 4+ years now and we've been free of everyday restrictions due to COVID for a couple of those years is a stretch that I suspect is not going to hold up for long when seriously challenged at a tribunal. The argument might have worked if an employer mandated RTO shortly after the statutory restrictions were lifted but by this point it's just normal practice and probably the only practice that many employees at the company have ever known.

If this is in England, that might depend on how long people have worked there and some other legal technicalities, but yes, handling this badly could be an extremely expensive mistake by the time they add up direct costs to existing employees who aren't happy and indirect costs of difficulty hiring good replacements.

In some cases, sure, but many social media sites function as a hybrid link aggregator and discussion forum. There would still be plenty of places designed and intended to share (with moderation/voting of some kind) links with other people who might be interested in them, even without any help from Google and friends.

Of course there would. In the early days of the Internet we had several ways to find interesting sites, while search engines as we know them today didn't even exist yet. Today we also have social networks and link aggregator/discussion sites (like the one you're reading right now!) that make sharing links to good quality content with other interested people a common and instantaneous act. If search engines became unreliable, the content creators would just start using inline links to other interesting sites more again, and viewers could go back to browsing around the web of information thus created and using bookmarks for their favourite starting points when they're browsing the web.

We didn't see any point in being subservient. The profit is a nice bonus, though. :-)

In our experience Google traffic is vastly overrated anyway. You can get volume through them but despite visitors theoretically being pre-qualified by already expressing some related interest, practically it's always been low-quality traffic for us, with conversion rates a small fraction of the rates for visitors who reach us via other channels. We therefore don't play the Google SEO game. We follow reasonable practices to make a good site that works well and our users actually like, but we totally ignore whatever whims Google is trying to impose upon the Web this week. And we have neither regrets nor any evidence to suggest that we're actually losing money this way.

I've heard many times over many years about how LinkedIn is essential. When I started doing some freelance work, I did set up a profile on there, reasoning that it's somewhere credible to put a summary of what I offer and maybe collect a few personal recommendations to build up some trust with future clients.

As far as I can tell, I spent a significant amount of time on LinkedIn over the years maintaining that profile and discussing potential work with various clients or recruiters on there, but I have never made a penny directly from those efforts. Not one actual paying gig has resulted from initial contact via LinkedIn. Even if I engaged with someone away from LinkedIn but linked to my profile there for background, almost no-one ever viewed it. Our own sites, an old school CV if actively applying for a specific role as a contractor, and of course real in-person networking through people we actually know, seem infinitely more likely to secure legitimate paying work AFAICS.

Obviously this is all anecdotal, but I do wonder how much the people who are posting drivel on there every day about how "I've been told I should post more about my secret orangutan fetish" (by their imaginary friend who just read a LinkedIn post about how the LinkedIn engine would like them to LinkedIn more, presumably) are a bit like the people who buy too many lottery tickets every week because one day, maybe just maybe, they might win big.

This is easily solved by legislating that users cannot in fact give up certain rights over their own work. Boom, no more problem with businesses that are providing a forum but not the actual content on that forum claiming excessive rights to everything users put there. The EU already took some big steps in this direction and those laws were aimed squarely at the big social media sites.

Fair point, Go does have form for being "heavy" in this way even in larger applications. Though I think it's also fair to point out that things can be done to significantly reduce the bloat in practice and part of the problem with Go is that those things aren't the default behaviour or sometimes widely known in the community. Other relatively static and pre-compiled languages like C, C++ and Rust don't tend to suffer from the same problem to anything like the same degree and do produce reasonably compact executables with pretty standard options for compiling a production build.

I don't disagree with you about containers, FWIW. My point is just that if you have a simple, self-contained executable file then you don't really need to worry about dependency encapsulation in the first place. Boring old compiled executables don't bring entire directory trees of third party dependencies along with them, at least not in a way that users will normally see or need to worry about. I'm not claiming they're the silver bullet that fixes all deployment problems or anything silly like that but I do think a lot of the industry seemed to have collect amnesia about the fact that a simple, effective solution like this was even possible for a while there.

And yes, it's true that micropython can be made very small, but then it also does almost nothing out of the box and so has quite limited applicability. By the time you've installed enough of the included batteries to make Python a useful option in the first place the footprint will most likely be a lot bigger.

You aimed a couple of orders of magnitude high on that one. And that's the price for statically linking the Go runtime. It's not as if it's going to scale proportionately with larger applications.

Compared to a Python runtime/virtualenv, which really can run to tens of megabytes unless you heavily manually optimise it (been there, done that), or hundreds of megabytes of junk in a node_modules directory for the 753 transitive dependencies you accidentally installed, a single executable on that scale for a complete production application is a bargain.

The thing is, I expect that the opposite is almost always true now. The bloat used to happen sometimes because many applications would all make use of a common library that would only need to be stored and loaded once if shared. But in practice libraries are often larger now and any given program often uses only a very small proportion of the code in them. Statically linking only the parts actually used and using a modern optimising tool chain could easily end up with smaller total executable size both on disk and in RAM even if several different programs that are currently running all happen to use the same handful of syscall wrappers and language standard library functions. And in any case the executable code part of a modern application is often so small compared to application data and the resources of the system that it's running on that even a bit of duplication wouldn't cause any harm.

There's still a valid argument about avoiding duplication in genuinely resource-constrained environments like embedded systems. At least in those environments you typically know exactly what you're putting in there and can make an informed decision about the trade-offs.

There's also still a valid argument about applying timely security updates where you only have to replace a commonly used but vulnerable library once system-wide if it's shared instead of updating everything that depends on it individually if it's statically linked every time. (Then again, there's a valid counterpoint that bugs or vulnerabilities in a bad shared library have a larger blast radius and can't necessarily be predicted or controlled by the developers of the software relying on that library the way they can with static dependencies they determine absolutely and can test as they see fit.)

So I agree that flexibility is potentially useful here, but I still think there is a lot to be said for having a single, self-contained executable file that can run on any platform with a compatible hardware architecture and interfaces for system services. Both of these often last on the order of decades while remaining stable or backward compatible. It seems to be increasingly the case that we're lucky if the runtime environments for all these highly dynamic systems last for more than a few months.