"This repository contains the majority of Tailscale's open source code. Notably, it includes the tailscaled daemon and the tailscale CLI tool. The tailscaled daemon runs on Linux, Windows, macOS, and to varying degrees on FreeBSD and OpenBSD. The Tailscale iOS and Android apps use this repo's code, but this repo doesn't contain the mobile GUI code."
and
"The macOS, iOS, and Windows clients use the code in this repository but additionally include small GUI wrappers. The GUI wrappers on non-open source platforms are themselves not open source."
On the other hand, while I suppose the Windows app is probably reasonably straightforward to replicate, I guess it would be much harder to produce an iOS or Android app because of the vagaries of mobile programming.
> I guess it would be much harder to produce an iOS or Android app because of the vagaries of mobile programming.
on iOS you also need a special entitlement that's only available on specific request and only to known developers, so practically impossible for any open source project to acquire.
Yep, Tailscale takes a pretty reasonable approach to that IMHO. Open source on platforms that are open source. I think that works out pretty well because it meets people where they are. For example the people who care about open source (and thus are running linux or android) get their open source needs met, and people who don't care about open source strongly or at all (as evidenced in part by them running closed/proprietary OSes) such as mac or windows users are also met where they are. Of course this also helps protect their business model because then competitors can't just take the open source versions and run off with them, and the number of linux users is quite small compared to mac and windows so it keeps the majority of the client closed while still providing the openness to those who truly care about it.
*In my perfect world everybody would care about open source, but the evidence is pretty clear that only a tiny minority of people actually do, even among engineers
* Does it work well?
* Do you recommend it?
* Do your users care?
* Is it difficult? Do you have to maintain it or is it basically set it and forget it?
* What was memorable about setting it up?
* Why did you go for Headscale vs Tailscale or Netbird or some other solution?
Very well! There are some limitations (see link above), but what's implemented is reliable.
> * Do you recommend it?
Yes, provided your requirements fit headscale's capabilities. If you need things like device trust attestation (e.g. Kandji MDM or Crowdstrike Falcon integration), SCIM provisioning, or various other enterprise features you may find it inadequate. If you can afford to pay for Tailscale, you should just use Tailscale because it's really good.
> * Do your users care?
They like it way better than our previous OpenVPN setup, that's for sure. I don't think they care about Headscale vs commercial Tailscale - the backend implementation is largely invisible to them.
> * Is it difficult? Do you have to maintain it or is it basically set it and forget it?
Not hard at all to set up, and it requires little maintenance attention. I have barely had to touch the control plane (other than version upgrades) since setting it up a year ago.
> * What was memorable about setting it up?
We had to do some custom coding to have automatic user offboarding when employees leave the company, and to emulate app connectors / dynamic routing (this is now OSS! https://github.com/singlestore-labs/tailscale-manager).
And I've been contributing to the headscale codebase to smooth out some quirks that affected our SSO integration. The headscale authors have been pretty flexible in welcoming outside contributors.
> * Why did you go for Headscale vs Tailscale or Netbird or some other solution?
vs Tailscale: It was way easier to build this myself than to get funding to use the commercial solution. I'm not good navigating corporate politics, but I am pretty good at building infrastructure and writing code.
vs Netbird: Mostly because I already liked Tailscale from using it at home, I like its implementation, and I like the way Tailscale (the company) have behaved. The handful of folks I know who work there are people I deeply respect.
> I can buy a brand new Ryzen 7000 series laptop for the price of replacing a Ryzen 7000 series mainboard for a Framework laptop.
I haven't been able to confirm this (I found laptop prices running at about twice the cost of the mainboard), but I wonder if you're comparing an EOL runout model from a place that can afford heavy discounts against a standard price from a smaller company. If you just need a laptop and you're not too fussy, that's definitely a fair choice. But if you're buying a laptop for ten years, you probably aren't going to settle for the unsold 16GB 512GB.
> Their laptops are also a lot more expensive than same spec branded ones from Asus, Lenovo and Dell that have better build quality and design.
I guess a Framework isn't for someone who wants a same spec Asus, Lenovo or Dell.
> Eventually, sooner rather than later, both RAM and SSD will come soldered on, so the only thing you will be able to replace is the battery and the screen.
This is 173% fud. If it happens, it's because Framework is dead and there's some different company that bought their branding and just wants to use it for market segmentation. I definitely have to rate the chances that Framework has died as one of the risks of buying them, whereas I wouldn't concern myself with the risk of System76 dying, because a typical laptop lasts well past its warranty, but the point of Framework is indeed what happens in that post-warranty period.
I'm not a huge fan of Frameworks. I left a critical review on another comment. I'm not sure at all if they fit my needs, and having recently discovered the wonder of tailscale I'm now debating if my next computer will be a Framework vs a headless desktop + a dumb laptop. So even if a Framework doesn't fit my needs, they're still the only laptop that seems to. But your criticisms don't at all seem grounded enough.
This is 173% fud. If it happens, it's because Framework is dead
Take a look at the Framework desktop, it comes with soldered on RAM. Not because of any active decisions made by Framework, but simply because that's how that CPU ships. It literally didn't support RAM slots. I can only see this trend continuing. I don't doubt that Framework will be the last hold out in the fight against soldered on RAM and SSDs, but sooner or later if they want to keep shipping the latest CPUs, they probably won't have too much of a choice in the matter.
My gut is that Framework shipping a desktop with soldered RAM was simply a compromise of opportunity, given the LLM boom and interest in AMD Strix Halo. I can only guess, but I'm betting the Intel desktop will not have soldered parts. I'm further hopeful that if folks need to upgrade this specific device that there will be a healthy second hand market hungry for them like there is for used Nvidia GPU's.
But I do agree that the trend of soldered SoC-like will grow, seeing that less than 1 in 10 consumers ever upgrade a computer. Apple silicon has been out for four years and I don't really come across a lot of grumbling about their integrated components which gives me hope that it's a tenable option and we're worried about nothing.
FW asked AMD about lpcamm memory and AMD looked into it (assigned an engineer and everything) but came back and said no it couldn't be done (I am guessing without crippling performance).
I would be in the market for the MB only but I think I can build a 9950 based system cheaper, but I am not running AI models locally.
The modular ports are just USB-C in a cutaway. You can plug your charger into the USB-C port, or into a USB-C module that plugs into the USB-C port. Totally underwhelming. (I had a Framework 16 as a work machine at a previous job.) I definitely still make use of USB-A, and I will for some time - but only when I'm at home plugging in my keyboard and mouse, so I could be perfectly happy with a USB-C hub like I use with my current laptop. I want a durable computer which I can upgrade the RAM, motherboard, storage, replace the battery, screen etc over the next seventeen years so that I don't know when one computer begins and the next ends. I don't want impractical USB-C ports that I have to pay extra for and which limit the durability of the system. To be clear: I've never had a laptop whose charging port died, but if it was something I'd rate as likely, I'd would much rather have a good system and replace the bottom cover kit, rather than a compromised system and replace a protective plug.
I’m not sure what you lose by the expansion bay port being an actual standard port rather than something proprietary I’m assuming is what you would prefer? There is a grip system where the expansion ports lock in, and the ports aren’t just hanging by the USB-c male, I have not heard of instances where the inner port fails. In fact, it’s pretty convenient and has come in handy for me that in a pinch you can remove the expansion modules and have extra usb-c ports.
I just searched for some colorised Roman statues and they don't seem to be overusing color. Even complex designs might be basically three colors (e.g. red, blue and white, plus with brown hair and eyes), and the colors themselves are a bit muted. I guess the have been painted based on modern interpretations of the original colors based on whatever limited evidence remains, so maybe those aren't the original colors, but it doesn't seem like a 1990s era website or a garish collection of first gen iMacs and iBooks.
What else could it be but a bitwise AND. If they had used `open_source && privacy_focused && user_controlled`, it would just be `true`, which is hardly an interesting philosophy. This way, you'll be able to do tests like `if (!(philosophy & privacy_focused)) { track_user_activity(); serve_creepy_but_useless_ad_about_something_they_bought_yesterday(); }`. Alternatively, they could have used some kind of set datatype if the number of philosophy variables is large enough, but I think the code would have become unmaintainable if they want to implement every possible philosophical alternative; 64 bits should be enough for everyone.
If you buy someone's domain name, then they'll probably have emails going to it. So you set up a catchall address and discover what accounts are related to it, then you can use the reset password functionality to get access to the accounts. In some cases, they'll have a backup gmail account - and perhaps you can guess what it is (e.g. emails come through to Paul Davis so you guess, oh, maybe they have the paul.davis google account, and reset password on that).
Ultimately, yes, programming with LLMs is exactly the sort of programming we've always tried to do. It gets rid of the boring stuff and lets you focus on the algorithm at the level you need to - just like we try to do with functions and LSP and IDE tools. People needn't be scared of LLMs: they aren't going to take our jobs or drain the fun out of programming.
But I'm 90% confident that you will gain something from LLM-based coding. You can do a lot with our code editing tools, but there's almost certainly going to be times when you need to do a sequence of seven things to get the outcome you want, and you can ask the computer to prepare that for you.
I don't necessarily want search to become any fuzzier than it already is either, but what's happened has happened and I've already responded to the decline of traditional search engines. Nowadays I pretty much only search duckduckgo with site:(something), or else I ask perplexity the question and for some links. Traditional search engines now just give a thousand SEOed-to-death articles, probably generated by ai, from hundreds of pointless third party websites that just have the same basic milk.
It might be that it's worth it to bifurcate soon. Search indexes and AI engines, doing different roles. The index would have to be sorted with AI though - to focus on original and first-party material and to downrank ad-driving slop.
"This repository contains the majority of Tailscale's open source code. Notably, it includes the tailscaled daemon and the tailscale CLI tool. The tailscaled daemon runs on Linux, Windows, macOS, and to varying degrees on FreeBSD and OpenBSD. The Tailscale iOS and Android apps use this repo's code, but this repo doesn't contain the mobile GUI code."
and
"The macOS, iOS, and Windows clients use the code in this repository but additionally include small GUI wrappers. The GUI wrappers on non-open source platforms are themselves not open source."
Moreover, there's https://github.com/tailscale/tailscale-chocolatey to aid the build process. I haven't built it or run it.
On the other hand, while I suppose the Windows app is probably reasonably straightforward to replicate, I guess it would be much harder to produce an iOS or Android app because of the vagaries of mobile programming.