slgeorge

London's basically great for:

  1. Startups
  2. Scaling/Growth
  3. Existing company expanding from USA->Europe or Europe->USA

For start-ups/high-growth you get a pretty good business environment (legal/corporate and day-to-day running a company is reasonably straightforward), employees with skills and the employment law is pretty flexible, there's plenty of finance around.

For Growth and USA companies that are expanding into Europe then London/UK is somewhat easier to understand than other European geo's. There's an aligned language and there's more cultural touchpoints - it's kind of a mid-point culturally/institutionally between Europe/USA.

For funding/driving to late-stage and IPO there just isn't anywhere like the USA. But everyone has to expand to North America eventually, so it can be fixed at that point. Also, PE funding has changed a lot in the last 10 years, so if you're not on the 1-in-1000 rocketships there's a more steady 'good' path which is totally viable.

As a Brit when I started doing deals in North America one of the things I picked up was that I had to be explicit about disagreement OR where a decision was not being made yet. In the UK during a negotiation a 'silence' is not equal to agreement or disagreement, it's a NO-OP. If I didn't do this then prospective customers/suppliers in the USA would believe that I'd agreed to their request when from my perspective I had merely noted that they'd asked for something. Has anyone else run into this?

The other one that's confusing is that "tabling" something means the complete opposite.

I would separate 'politeness' and 'indirectness' a bit. I generally agree about 'politeness', there are plenty social forms that Brits still follow. For example I found the language/manner of New York attorneys pretty 'aggressive' the first few times.

Indirectness, is definitely a thing - Brits speak to each other or signal disagreement in ways that's clear to another Brit, but maybe not others. The use of silence, but also some words that depending on tone can mean different things which I think is difficult for North American's to interpret.

Do you have an experience working in Europe or the UK?

I couldn't even hope to get employment in tech in the UK or Europe without a degree

Maybe this is how it looks from the outside, but it's not how it works in reality.

My evidence is I've been working in 'tech' for 25 years and having hired people across the UK, Europe and North America. Tech is one of the most accessible career paths, particularly for areas that are novel and expanding rapidly - consequently direct experience of an area is the important currency.

Often roles will advertise a 'degree' or equivalent industry experience. The only roles I can think of where this could be an issue is trying to join a large corporate organisation in their 'graduate' programme (e.g. a major bank), but that's the same situation in the USA as well.

Guix is gathering feedback from users and contributors on their experiences; what they love and what they've found challenging. Whether you're new or a veteran we'd love to have your opinion and comments!

As the projects never done this before it should be super interesting. So submitted this for anyone that's a current user, or tried it in the past.

For those that don't know Guix is like Nix, but uses a single language (Guile Scheme) to define and configure the system. It's has four elements:

- a package manager that can runs on top of any Linux distribution (e.g. like homebrew)

- a dotfiles and home environment manager

- a complete GNU/Linux distribution

- a way to create isolated development environments

"Modern" seems to be used a loose adjective these days for "I rewrote $thing [in Rust]". Minecraft was created in 2011, and is Wikipedia says the last version of the 'classic' edition was released in 2017. So anything after 2017 is now defunct.

I don't mind people rewriting things in <insert-name-of-tech-I-like> but "modern" as a value seems pretty loose, and it's often at least arguable whether it's objectively better!

I use it for additional packages on top of another Linux distribution (Ubuntu). This gets me rolling release packages and guix shell which is great for development as each project I'm working on can be completely separated.

For 'servers' the nice part is being able to prepare a declarative operating system configuration and play with it locally (VM), then it can be deployed to the remote node and you know it's going to be the same. If something goes wrong it's easily to declaratively roll-back. Here's a nice starter post (https://stumbles.id.au/getting-started-with-guix-deploy.html). The deploy capability definitely needs more hoops to jump through and it's not without rough edges - but I think it's really cool. There's active ARM and RISC-V work - I don't know how rough that would be compared to the well-known ARM ports - ask on #guix if you're interested.

Yes, I wasn't throwing shade on Nix, I was drawing a specific comparison about Linux distributions.

My opinion is that Guix/Nix move the state of the art for Linux distributions forward. So Guix<->Nix are both similar Linux distributions, and different from previous approaches (e.g. Debian, Ubuntu, Redhat etc).

Transactional package management and declarative system configuration solve a whole host of problems. Guix (and Nix?) directly integrates configuration management into the OS, rather than as some adjunct piece of tooling (Ansible, Terraform etc). We define the packages, the system, the configuration using the same DSL. Transactions and a declarative approach improve maintainability, reproduciblity and might limit the amount of time I spend messing with different tooling ;-)

We're a small group 5-10 people, so it's very informal and friendly. I'm sure Fabio (https://fabionatali.com/) who organised it would have good advice! I'll say that from my perspective the fact that it's also virtual is really great as otherwise I couldn't attend!

No.

Guix is more similar to Debian, with only 'Free Software' applications in the main archive.

For proprietary codecs, firmware and so forth there is the Nonguix channel. Again, this is fairly similar to how distributions like Ubuntu have handled this line in the past.

I need Chrome and also have some games loaded using 'channels' - heh heh - another post:

https://www.futurile.net/2022/12/04/proprietary-apps-on-guix...

A lot of Guix users use Flatpaks.

New packages and updates to packages come into the archive continuously. For example, in roughly the last 24 hours 40 packages were added or updated - https://git.savannah.gnu.org/cgit/guix.git/log/ . Advantage of this is that you can use new packages immediately and there's no big 'upgrade'. Challenges are that if you were an enterprise and wanted to stick on an 'old' version this wouldn't the right distribution.

Guix does receive security updates, and those are added to the archive immediately. I haven't had any problems myself. It's definitely a 'community' project, so you have to enjoy doing a bit of hacking!

Guix can create reproducible development environments that are "sealed off" from the rest of the distribution. It's called Guix shell and it's very flexible:

* Guix Shell https://www.futurile.net/2023/04/29/guix-shell-virtual-envir...

I did two specific posts about using it for 'development' environments. You can also 'fix' the environment (think a git hash) and use the declarative configuration to share it with others:

* https://www.futurile.net/2023/04/30/guix-reproducible-dev-en...

* https://www.futurile.net/2023/10/17/guix-time-travel-dev-env...

Hope they help - if you have a play and get stuck the mailing list is really good and I posted about the Meetup further up.

For those that don't know Guix can be used as:

* a package manager on top of an existing Linux distribution (think apt or rpm)

* a development environment (think Python venv but for any language)

* a VM system (like Docker but declarative)

* a Linux distribution (similar to Nix)

It's a small and friendly community - we recently started an English-speaking online user-group:

  https://www.meetup.com/guix-london/

I also did an Intro post to some of the advantages and challenges a couple of years ago:

https://www.futurile.net/2021/09/26/guix-alternative-to-snap...

FFS - talk about missing the point.

Sorry that annoyed you.

One thing to bear in mind is that at Weaveworks we made massive contributions and did our best to be part of the community in the right way:

* Flux * Flagger * Cortex * Ignite * Weave Net * and a whole host more

Oh and there's a load of people without jobs tonight - wondering about their futures - hopefully people will see the talent and the contributions and find roles for them.

Thank-you - really appreciate this comment - acknowledging the work that great people did and the efforts they put in. I wish the outcome was different - but we really tried to do good things, and play well in the open source community.

The shutdown means great people with Cloud Native skills are available now.

People across all teams: marketing, product, engineering, dev-rel, consulting / CRE, customer success and business operations

Across the States, UK/Europe and Egypt.

If you can help these fantastic people find new roles - please get in touch!

I am so freaking sick of companies lying and exploiting open source. This is Embrace, Extend, Extinguish at it's finest.

I don't see how this is 'Embrace, Extend, Extinguish'? This license guarantees that the code becomes Free Software at a maximum of 4 years - and in this case they've specified a shorter time period.

I'll give you that there are lots of games played in open source, so I understand that feeling of cynicism. But, this actually seems like an attempt to add some nuance to the commercial<-->free divide.

The reality is that many 'commercial' OSS companies have to take the open core route because understandably investors expect a return on their money. There are exceptions to this, but they are pretty rare. In fact, there are probably a whole set of SaaS companies that could be open source, but don't do so out of the fear of someone taking their code and 'free riding' them.

Finding a way to prefer the entity that sponsors/incubates the code base, while also genuinely allowing a community of contribution around it (not free riding) would be very beneficial in lots of situations. Maybe a better critique would be that this has some similarities to the Trolltech QT approach - but that's a different argument.

I think you know this as you mention "olden way" - it's definitely the thread of history where most UNIX servers were multi-user systems: that's how I was first exposed to Unix, even though by late 80's/early 90's most of them were Linux or a *BSD. In those - presumably University mostly - environments, we mostly sent email to each other and that was often between servers on a campus or environment. It made sense then that each server sent email because you were specifically user@host.someplace.

When the distros started to expand, being a smarthost was the most common configuration. Today, I agree with you the only reason for any sort of SMTP daemon is for programs to send email - all the users are on Google/Slack.

I've been using Guix on top of Ubuntu so that I can have the latest versions of some applications I care about, while keeping the core Ubuntu which works well with my hardare.

Similar to your comment the ability to see exactly what is installed, with repeatability is fantastic. For my personal use-case the ability to install an application in parallel to Ubuntu's is really useful.

Finding that "intrinsic motivation" to work on a hobby is something that really helps to keep you going. Often we're extrinsically motivated by others praise, social media likes ete. While praise is no bad thing, it doesn't always happen or you can be knocked off course by negative feedback.

I'm often amazed by the intrinsic motivation and long track records of people working on open source.

Totally get it. But, the issue is that to sell something it has to solve a problem for someone else. Generally the choices are:

a. Build something that solves your personal problem - later find out if that applies to others, and whether they are willing to exchange money in return for a solution. b. Find out what problem others have (ask them if they'd pay for a solution) - then build something that solves it responding to their feedback (if it does, ask for the money they said they'd give for a solution).

Maybe another way of looking at it is that (a) is about saying what "your vision is", and (b) is about finding out what "someone else's vision is".

Following (b) is a better commercial/sales strategy, but you're right that it might involve building something that you don't care about - because it's not for you, it's for the customers - which is probably why it's work and we do it for monetary compensation rather than just joy.

Perhaps the most difficult outcome is that many Founders now read product books or go to accelerators where they're told to follow strategy (b). They then basically do (a), while pretending they're doing (b) - but really all they do is listen to people who are positive about their vision and ignore any counter evidence.

That's pithy but a characterisation that misses many important aspects.

Bram's been developing Vim for 30 years [0]. Just think about that for a second. An open source project that's been running for longer than the age of probably 50% of the readership on hackers news. It's ways of working and values have been developed over a long period of time.

Vim favours being available on multiple platforms, alignment with Unix tradition and stability:

Vim is a highly configurable text editor built to enable efficient text editing. It is an improved version of the vi editor distributed with most UNIX systems. (https://www.vim.org/about.php)

Neovim is built by people who value fullness of features, who see multi-platform as 'legacy platforms' and are happy to break backwards compatiblity for the value of making something more complete by contemporary standards.

The easiest summary is - Bram's comparison is Vi, Neovim teams' comparison is VS Code.

I love many of the NeoVim's new features and capabilities.

But, I think it's possible to like Neovim while also understanding the positive value of Vim and why their approach is different. There's something in the human condition about turning everything into a winner and loser, a hero or a villain - but it's just not true.

As a project that's been running for 30 years Bram and that community have an approach that they are comfortable with. There's a way of working, and a rhythm to the project that has worked over the long-term. They're evaluation of changes is against their own internal values - those values are different to the people that are working on Neovim. Personally, to me 30 years of effort and contribution to providing something totally free is unbelievable.

[0] https://en.wikipedia.org/wiki/Vim_(text_editor)

True - but you're forgetting the executives previously learned experience of telling a team that a due date was September and them delivering six months later. The consequence was missing the marketing/PR window, negatively impacting the future valuation of the company, reducing sales and leading the board to fire the executive.

... most people aren't arbitrary, they have different experiences or perspectives which leads them to 'rational' decisions.

Actually ...

It's equally hard to do good or bad management, since most of the time you have no idea if you're achieving either outcome - and neither does anyone else.

The problem with all forms of management is that it's completely unscientific. The main resource you're working with is a "human" which has emotions and who will respond to inputs in very different ways depending on all sorts of factors you as a manager don't know about.

And, when you put a group of "humans" together you might expect a direct increase in productivity - 6 humans should be 6x more productive right - you'd be wrong. Also, for whatever reasons the dynamics of the individual humans change in groups! They are differently productive depending on what other humans they work with! And, since there's no scientifically proven way of categorising them - you can't even tell which ones will work well with other ones.

Oh and the big joke, even if you get that working, sometimes they *change* and then some part of the group is broken for some unknown reason.

Then there's the problem of measurement, and I don't mean the team members. As a manager trying to measure the outcome of your own efforts is difficult, bordering on impossible - maybe something you did changed something, on the other hand it might be some other factor you know nothing about.

Finally, you might expect that the individual "humans" might know what makes them individually more productive. But, nope - most humans have no idea what makes them individually more productive, and then throw in a team setting and you're in a whole world of pain. Some of them think they're "analytical" and can't tell that they're dragged around by their emotions, love life, caffeine, commute or sunshine quota. There's a variety of 'received wisdom' stories they tell themselves, but it's often just a random walk.

So actually ALL management is hard, and you often have a equal chance of doing it "well" or "badly" on pretty much a daily basis. It's as hard to do it badly, as it is to do it well since most of time you're not sure if either is happening.

I wasn't trying to set up an "opposition" on the language level in my sentence. The decision was couched in my personal constraints - whether "as a hobbyist" it was practical for me to learn the language successfully. And, having done so would it have the capabilities so I can build things that I'm interested in. For me personally, I like to have plenty of 'similar code' so that I can see what other people do. I was comparing this with a more academic approach which I've seen many Lisp learners enjoy - for example going through the Structure and Interpretation of Computer Programs (SICP). Other languages I looked at and seemed interesting were Elm and Racket - no particular reason why they didn't stick.

I suspect a lot of the dynamics of my choice are because I wasn't coming from any sort of Lisp background previously. If you were coming from Common Lisp then things would feel different.

I've been messing with Clojure/ClojureScript for a few years having previously had zero Lisp experience. Overall, I think Clojure does a good job of being both practical and lispy. It's a language that is for building real things.

I've been focusing on ClojureScript (https://clojurescript.org/) as you get the benefit of interoperating with the Javascript ecosystem. The fact that there's a strong community around both Javascript hosted and Java hosted gives a wealth of library options.

Overall, the tooling has been getting a lot closer to the sort of experience that contemporary developers expect. The Calva plugins integration with Visual Studio (https://calva.io/) makes it easy to get started - you can even run it online with gitpod (https://github.com/PEZ/rich4clojure).

That just leaves learning the language - the slight changes in syntax (brackets for different data types) definitely help early on, and for the most part Clojure discourages people going down the path of macros which means reading other peoples code is reasonably accessible. The main struggle is that it's a language used by a lot of advanced or full-time developers, so documentation is pretty dense and it can take a real commitment to understand the detail.

It may not be 'correct' enough if you're coming from other Lisps, but coming the other way from C/Python etc I've found it an accessible and practical option.

For Clojure on the JVM I've seen etaoin (https://github.com/igrishaev/etaoin) and there's clj-chrome-devtools (https://github.com/tatut/clj-chrome-devtools). I would ask on Clojureverse or the Clojure Slack/Zulip for opinions.

For ClojureScript I guess there's lots of options since you can access the Javascript ecosystem.

One of the benefits of being hosted is that we can always fall back on the host language's options.

It goes against everything open source stands for

Sorry, that's not correct. It goes against your opinion of what open source should stands for, and many projects run in a way where everyone can contribute. But, it's not the only way.

The license determines how the code comes, that's the only rule. There's no rules about how a community must run. It's for the code creator (maintainer) to determine how or even IF they want a community of contributors. There's lots of ways of doing open source!

And saying it's not "open source' if you don't do X outside the license is just a No true Scotsman.

I voted you back up because generally I agree that using weak value judgements (e.g. X is old fashioned) without saying WHY a particular thing needs to be improved is not very useful.

In fairness, in the article he does say why all these communications tools are a problem in his opinion.

Absolutely. Remote working is absolutely devastating to the development of junior team members and people just getting started in the world of work.

If you're just getting started in your area (whether development, sales, marketing, devops) having immediate help and guidance from your peers and manager is really helpful - documentation helps, structured training helps but they're not the full solution. Those momentary 'quick' bits of guidance help, and whether we like it or not "face-to-face conversation" is the highest form of bandwidth we have.

The other element people don't talk about enough is that getting used to "working" is a journey in and of itself. There are lots of elements of being productive in the world of work - not just churning out code - and it's not obvious how it all works. In some areas I see a lot of "hollowing out" where we don't have as many entry roles.