Response to “WireGuard: great protocol, but skip the Mac app”
lists.zx2c4.com
lists.zx2c4.com
Last year Google started to ban donation links in FOSS apps, WireGuard was one of the first victims [0], completely removed from the store. I didn't know that Apple also started doing the same and hit WireGuard again. Extending the definition of an "in-app payment" to a link to the project homepage in the "About" window that doesn't buy any good or service related to the app is an overzealous restriction. Especially so when that button is clicked by, perhaps, only 10% of the users. This is just evil.
[0] Open-source apps removed from Google Play Store due to donation links
I can imagine that Apple may want to define 'FOSS' to some extent (donations need to go to a non-profit with a board, software needs to be licensed under one of the following licenses, etc), but there should be some room for supporting FOSS that is included in an App Store.
Heck, if both Apple and Google offered a solution by which you provide the source code to build, any necessary secret variables for the build and then it gives you those extra privileges, it would be nice. But that costs money the open source apps don't have.
"The stuff we won't pay for, but will make other people pay for, even tho we did nothing for it"
10%? I think FOSS developers would be extremely happy if even 1% clicked on that kind of button. I reckon the actual stat is closer to 0.01%...
This is absolute scroogerism from our mobile overlords. We badly need a really-open alternative to the Google/Apple world of feudal taxes.
F-Droid is a thing
When they change that optional setting they introduced recently which blocks sideloading applications outside of the official store and make it non-optional, what are we going to do? Use special Chinese Android builds with Ali store (or whatever it's called)?
Boiling the frog slowly and all.
Regular Android works great in GrapheneOS/CalyxOS/other AOSP variants.
This kind of response completely ignores the fact that the vast majority of the drivers required to just run on modern hardware are closed source and that the vast majority of phones these days have their bootloaders locked.
I don't know if that is actually still true. Back in the day nearly every phone in the US was bootloader and carrier locked. Now basically every phone is carrier unlocked and anything besides Samsung can have the bootloader unlocked very easily. I guess Samsung phones are the most common but there are certainly many other options that are more open.
Many manufactures make it easy to unlock and root your device (shout-out oneplus), but many others do try to make you brick it if you try doing anything out of the ordinary. Like the HMD rebrands Nokia, Sharp, etc.
Here in europe, you go to developer mode, check the OEM unlock button, reboot and hold some weird button combination while booting, phone asks you again if you want to unlock the bootloader, does a factory reset for security reasons, another reboot, and it's unlocked.
And then, of course, applications like your banking won't work, because they require Google SafetyNet attestation for your security.
All my phones are rooted and it has never been an issue with any banking app I use. It's all about priorities. For some people, that's going to be the roman numeral name suffix dropdown in the registration form. For me it's the bank not telling me what I can do with my devices.
Because it is pushed centrally, banks do not have a choice. Hence, you as a customer, won't have a choice either, unless you consider not using the bank online at all as a choice.
Banks are forcing you to run proprietary software on proprietary operating systems with draconian "security measures" that would make the latest DRM-enforcing-rootkit look like a children toy. They check whether your device is rooted, whether it has any non-Google-approved programs installed, whether Google Play notifications work, etc. And if you fail any of these checks, good luck using your credit card!
Open-source operating systems are basically dead in the water at this point, since failing to run these proprietary programs is not going to be a minor "I can't play this game" level- nuisance, but rather a life critical issue. And so far more and more banks keep enforcing these measures.
And for some reason there is no big outcry about this.
Even Korea's "all banks require ActiveX" situation was very mild compared to where we're going...
Encrypted push notifications are much better.
PSD2 lets you do basically whatever you want. Fingerprint is enough, or confirm in phone app if making a transfer from a desktop banking UI.
U2F would be nice but with banks being banks that's not going to happen this decade.
Why? Because even with "Google" phones, installing pure AOSP cripples the phone (and by that mean SMS breaks with LTE, you lose voLTE, Wi-Fi calling, etc.) A lot of Android ROMS have to scrape official images to get the binary bits (and it is nor a fun needle in a haystack excerise) to get basically phone functionality in Android.
What setting was introduced recently? I remember such settings all the way back to the Nexus One.
In fact, things were more closed back then as Android phones bought from AT&T had it hard coded to disable third party apps. I'm not aware of a US carrier doing that any more.
Otherwise: send complaints to support@android.com (jk, there's no actual support)
Nothing is preventing these apps from simply saying 'if you want to learn more or support our project go to <some top-level URL>' instead of directly linking the URL to a donation. Do that and there is no problem.
1. App links to developer's blog. At one point the top post is about their patreon. Apple removes app until post is amended.
2. Also apparently the bandcamp app has no links to their website, for the same reason.
https://news.ycombinator.com/item?id=19378914
Amazon Kindle app could not link to amazon.com as users could purchase books there without giving apple their cut
https://apps.apple.com/us/app/united-way-of-chester-county/i...
They have a donate button (last image on right). Does Apple take 30% of all that is donated? If so, I find that to be repulsive.
[0] I picked Unite Way because they're a large org, not because of any other reason.
Update: Apple Pay appears to have similar policies [0].
The rejection is wrong, because the App Store review guidelines clearly spell out that apps may request donations through Safari. On the other hand, apps cannot use in-app purchases to request donations, unless they are published by an approved nonprofit.
3.2.2 Unacceptable
(iv) Unless you are an approved nonprofit or otherwise permitted under Section 3.2.1 (vi) above, collecting funds within the app for charities and fundraisers. Apps that seek to raise money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS.
Collecting funds "within the app" means that the payment flow is completed without leaving the app. They explicitly list two ways for any app to accept donations, by redirecting the user to an external web service opened in Safari, or by collecting payments using a text message.
You obviously have to somehow communicate to the user that donations can be made, and that is allowed to happen by showing an external link.
Which e.g. "PayPal@zx2c4.com" is not, clearly.
The words you are missing are important.
One of the reasons why I do not gift money to WireGuard developer(s) is that they have taken the steps to obscure where and to whom the money is going, which is in and of itself fishy. Just labelling something as 'donation' does not make it so.
[Edit: line breaks]
> One of the reasons why I do not gift money to WireGuard developer(s) is that they have taken the steps to obscure where and to whom the money is going, which is in and of itself fishy. Just labelling something as 'donation' does not make it so.
Your remark about WireGuard developers being fishy and obscuring where the money goes is ridiculous, and the way you framed it, just... wow.
3.2 Other Business Model Issues [list is not exhaustive] 3.2.1 Acceptable (vi) Approved nonprofits may fundraise directly within their own apps or third-party apps, provided those fundraising campaigns adhere to all App Review Guidelines and offer Apple Pay support. These apps must disclose how the funds will be used, abide by all required local and federal laws, and ensure appropriate tax receipts are available to donors. Additional information shall be provided to App Review upon request. Nonprofit platforms that connect donors to other nonprofits must ensure that every nonprofit listed in the app has also gone through the nonprofit approval process. Learn more about becoming an approved nonprofit.
3.2.2 Unacceptable (iv) Unless you are an approved nonprofit or otherwise permitted under Section 3.2.1 (vi) above, collecting funds within the app for charities and fundraisers. Apps that seek to raise money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS.
It would appear that the current understanding is that if you are not a nonprofit, you don't fundraise within the app nor do you provide a link where you can transfer funds. If you are a nonprofit, you can register through the nonprofit program to use Apple Pay (which comes with actual checks of the status). This matches the intent every other point regarding payments, where soliticing money from within the app, even by way of link, is generally prohibited unless specifically allowed under one of the small list of exceptions. Remember when "reader" apps also had to remove links to purchase individual items and replaced it with, at best, "visit our website"? Same intent, same result.
As for fishiness, compare these examples: * Signal Technology Foundation is a registered nonprofit foundation, I can check if the money is going to development of Signal (it is). They even do it right by providing the EIN so it is trivial to check. * Mozilla Foundation is a registered nonprofit foundation, I can check if the money is going to the development of the browser (it is not). * WireGuard developers decided it is important for them to keep the information where their business is located private (this is what I am referring to as fishy: I would challenge you to find where that particular "Edge Security" firm is actually operating, as a company, or what zx2c4.com is beside a name that Jason used to tag some files and host a domain, and both are used as "this project is from") and to keep the profits.
See the difference? Two are genuine nonprofits entitled to donations, one is a business disguised as one (how much money that business makes is immaterial, it could be $1, it could be millions - I sincerely wish them the latter). Every developer has to make a living somehow - or at least recoup some costs, for FOSS projects - but this is not the way to go about it if you want to claim moral high ground over Apple.
The argument for the ruling being bad is: the app links to the wireguard webpage (not within the app) which contains information on how to donate. That's like if in my app, I linked to my twitter profile, and my twitter profile contained a link to donate to me. It shouldn't be a problem.
If you are an actual nonprofit, you get to ask for donations both via app and your website and have Apple not take the cut.
Don't like it - don't deploy on the platfrom, but if you persist you will soon run out of platforms. Note that particular point has also caused WireGuard to be delisted from Google's Play Store before so it should not come as a suprise to anyone (https://news.ycombinator.com/item?id=21268389).
Note that some of those distinctions are legal - where I am, I need to know if I am gifting you money or donating to a nonprofit to report it on the tax record (and I certainly need to know if I were to get my own limited company to "donate"), as going above certain limits makes _me_ liable for tax on gifts as well, including reporting who the recipient is. "I sent that money to a random functional email PayPal@zx2c4.com I can't say much about" does not cut it. Yes, Jason might be at the other end of it - but as is, it fails the smell test compared to other FOSS projects. Simple as that.
Can we go back to discussing why Apple is bad due to their ever changing APIs, general disregard for backwards compatibility and for that matter general compatibility with anything else and not one of the few things in the whole process that make sense? Or, for that matter, why Google effectively making GMS and locked bootloader a requirement for corporate and/or finance apps is ensuring that in many areas the existence of unlocked devices/alternative AOSP distributions is and will remain a fig leaf purely there to avoid being considered the one true dominant player?
I mean, maybe in a technical sense? But the ones who publish these apps are usually just "non-profits run by single individuals who can't afford all the bureaucracy required to run a non-profit."
Keep in mind that FOSS apps like WireGuard are 1. entirely free, 2. with no ads, restrictions, or nags to donate. There's nothing you get from the app, or from the developer, by sending them a "monetary gift." Other than the fact that you can't claim it on your taxes, they're effectively working for a non-profit that produces this software.
If you consider someone offering a link to send them "monetary gifts" to pay their own salary to allow them to continue to work on an app they don't charge for, "a business" — I'd hate to see what you call a church, or a library, or PBS.
Churches are "complicated" - and less said about the funding the better, especially in context of the US. Suffice to say I very much prefer the German model - which happens to come with quite stringent accountability requirements.
I have no problem sending money in appreciation for the work with no expectation of any return on it (not even a tax deduction). I do not have a problem with someone making a profit on those "gifts" - I wish them all the best, in fact. I do, however, firmly believe that you can't have your cake and eat it too: you receive the ability to accept donations in a way where you enjoy various exemptions (in this context, from Apple/Google delisting you or taking their cut) in exchange for actually going through that bureaucratic rigmarole to get registered. It's not a $DEITY-given FOSS right.
Side note - as I wrote before, my local tax office would like to know who the money is going to, to either try to get their pound of flesh (cynical and realistic view) or to identify the money going to 'bad actors' (take your usual terrorists/criminals/think of the children BS excuse the politicians always make up to pass the relevant law), doubly so when the money is sent internationally - if I wanted to actually send an one-off gift to Jason/zx2c4, I can only assume he is not in my country.
[0] https://www.pbs.org/about/producing-pbs/funding-standards/
You seem to be assuming, though, that "not being a registered nonprofit" automatically implies that there's some non-trivial probability that you'll be profitable.
Every FOSS developer I've met who is accepting "tips" for their work, is not anywhere close to "breaking even" from those tips (insofar as you'd treat the FOSS project as its own business with its own balance sheet, rather than as a marque of the owner's hypothetical individual-proprietorship IT consultancy.)
Sure, some of these are side-projects they do in addition to a full-time job, and therefore the self-employment-wages they get paid out for this effort are "pure profit" in the sense that they already make a living wage. But that would be just as true if they worked full-time for a business, and then worked as a part-time paid employee of a nonprofit.
Profitability of a FOSS-project-as-corporation, is what's left over after you pay yourself (the sole employee) out at a working wage for all the labor you put in. As such, in legal terms, these side-projects almost always would qualify as non-profits.
FOSS developers aren't YouTubers with a fanbase of millions and a platform where they can directly, incessantly plug their Patreon to that captive audience with embedded advertising. They're just people publishing apps, where the app almost never event hints at the "personal brand" of the developer.
And so, I think a critical difficulty in the communication here, is that you might be imagining this thing on the wrong scale. We're talking about maybe 200 people per year, sending the developer maybe $5 apiece. Not about individual transfers of hundreds/thousands of dollars; nor about enough transfers to pay a living wage. That's why it makes sense to call these monetary transfers "tips", rather than "funding."
And that's also, partly, why people are so confused/appalled — Apple and Google do not serve their own bottom lines by getting in the way of people "donating" to these FOSS projects. The labor-cost required to enforce this directive probably costs more than they'd ever make by taking a cut of these tips!
> in exchange for actually going through that bureaucratic rigmarole to get registered
It's not the "rigmarole" (labor), it's the cost. A nonprofit corporation is still a corporation — and most FOSS developers, as individual proprietors, don't receive enough in tips to actually be able to afford the fees involved in incorporating and registering a nonprofit.
(I mean, they can probably afford it themselves. But the hypothetical nonprofit that is the FOSS project can't afford to pay for it out of its own treasury. I.e., incorporation would just put the FOSS project further "in the hole" in being revenue-negative, and therefore in being worth the developer's time to contribute to.)
There's a reason that governments allow individual proprietors to just "do business" without incorporating: it's a fiscal stumbling-block that trips up the people governments most want to encourage to start businesses.
The same thing should be true for nonprofits/charities, intuitively. Even if there is no legal recognition for "individual proprietorship nonprofits", everyone acts like those are a thing. (They don't expect their donations to be tax-deductible, but most people in the middle class don't donate to formal nonprofits enough to realize "donations" are their own, tax-deductible, class of thing, separate from regular monetary gifts.)
And most of all, people expects corporations to go along with it — and most corporations do go along with it. Microsoft with Github Sponsors, etc. That's why everyone is so up-in-arms that Apple and Google aren't going along with it.
Of course, Apple and Google are technically, legally in the right — these are not donations. The problem is that common sense disagrees with the law: by common sense, these should be donations, tax-deductibility and all. If push came to shove, the law — not common sense — would be what bends. But nobody's pushed that far yet.
> Side note - as I wrote before, my local tax office would like to know who the money is going to
Is there some problem I'm not seeing, tax-wise, with sending small monetary gifts to people you believe to be individuals who are online acquaintances of yours (e.g. people you talked to on a forum once)?
If I want to send money to a FOSS developer, it's because I view them as, effectively, an acquaintance. Someone I'd buy a beer at a conference. By "donating" to them, I'm just buying this acquaintance of mine a beer asynchronously.
Most people make small monetary transfers to individuals they aren't sure of the identity of all the time. For example, buying hand-made jewelry at a pop-up street bazaar. There's no "business" name — it's just an individual proprietor — and you might never learn the proprietor's name, either!
Because there are so many situations like this that can arise in every-day life, it's never the job of private citizens to prevent money from being unknowingly laundered into the hands of trade-embargoed states or entities. It's not your legal civic responsibility to avoid shopping at a store just because you haven't ruled it out as being a money-laundering operation.
Instead, it's the legal duty of banks and payment processors — with their fancy KYC/AML databases — to do that: to identify the transfer recipient through network-analysis at point of fan-in. Money launderers aren't fought by starving them of demand; they're fought by deplatforming them from the financial system they depend on.
(That being said, if you were acting as your own payment processor, ala https://en.wikipedia.org/wiki/Hawala, you might be on the hook at tax time.)
If Jason is recommending a way to donate to the project, who cares where it goes? If he puts it straight in his pocket and uses it to buy pizza or a computer game, it's still serving its purpose as far as I'm concerned. I have donated, and will do so again, and I'm perfectly happy with the money being used that way.
In a sense, for me, it's a thank you for the work thus far, not an payment for more work.
I imagine many see this differently, so I'm interested to hear some other opinions.
This could be normalizing effort; no end runs around allowed in software from our repo?
It’s rather our fault though, yeah? For popularizing their kit and agreeing to pay for “package management as a service” as devs in the first place.
The absolute opacity of Apple's technical policies and their arrogant i-dont-care/its-your-problem approach against developers are quite renewed in the community. This ends up costing a lot of development time to developers who mostly work for free, who struggle to reverse engineer or debug what happens on MacOS/iOS, and (like Wireguard's case shows) it harms the reputation of their software because people tend to blame the application rather than the OS when things don't work as intended.
If people want to use FOSS software, then they should be able to do so on systems that support the FOSS ecosystem, that provide developers with appropriate tools to debug what's going on (ON ANY PLATFORM) and sufficient documentation for them to understand how a certain component of the OS is supposed to behave.
I know that in the past 15 years lots of tech-savvy people have opted for Apple products because "they're still UNIX under the hood, and unlike Linux they just work out of the box". But being Unix-like DOES NOT mean to be developer-friendly! Apple is still an opaque developer-unfriendly company even if it provides you with a native bash!
That was true over 10 years ago (was certainly a big factor for me), but i'm not so sure it is for most people anymore. I remember back when I bought macs (more than 11 years ago now) they used to proudly advertise their "UNIX" certification and tout the BSD/Mach origins, I think this is when most of the original OS team was still there.
But today it seems to be one of the most neglected aspects of the system. Each time one of my colleagues with a mac tries to run one of my considerate bsd/gnu friendly scripts I discover most of their userland has not actually been updated in 10 years. I end up getting them to install brew and replacing every binary used in the script... and yet bizarrely things like ZSH suddenly pop up as the new default shell.
At first I was really into setting up everything just-so on the Mac, with an environment so closely mirroring the production servers that I was confident I could deploy stuff from there to staging.
But in the last few years, I ended up just having a reproducible set of dev and stage-like Docker containers. That way I can do all my coding in my nice shiny Apple UI, and all the build/test/run stuff happens in a place I have full control over.
This probably doesn’t solve everyone’s problems but for me it was the best way to have my Linux cake and eat my candy Apple too.
And yeah, the ZSH thing was super annoying.
We're stuck with this problem until the users have a bad enough experience that they move to a better platform.
The EteSync experience is subpar on Apple devices, and there's almost nothing we can do about it. We already spent countless of hours trying to fix things, but Apple just make it impossible. We have more ideas on how to fix things, and we will keep on trying, but it's beyond me why would anyone willingly use an Apple product.
Edit (adding one more point): that's one of the more annoying parts about Apple being the gatekeeper to 40% of the US population and in effect, to 100% of businesses (because one bad Apple in the org is enough to spoil the whole bunch). As a developer, you are just stuck with no way out.
Final users don't see this mess.
For all the criticism about how Fortnight framed its issues on iOS (and some of that criticism was warranted), coming out of the gate strong with a consistent message that Apple was to blame was likely the only way to get any 'normal' user to even consider that there were multiple issues and viewpoints at play. There's no such thing as subtlety or nuance when you're trying to talk to that demographic about why their phone/desktop doesn't do the thing they want it to do.
In the long term, I don't know. On one hand, these issues do affect final users, but communicating with final Mac users is difficult.
But on the other hand, Wireguard isn't going away, it's a clearly better protocol. So right now, final Mac users assume it's the devs' fault. But are they going to assume that when literally everyone around them has decent VPN clients and their Mac experience is just miserable? Mac users aren't completely isolated from the Linux/Windows world, at some point they're going to realize the pattern if all of the software on their platform is just worse.
This isn’t a moral judgement. I apply the blame to Apple. But I also choose to keep using their product. Their products are less dispensable to me than another VPN protocol.
I think the issue is less people who understand the tradeoffs and decide that the Mac platform is still worth using -- it's people who do not understand that there is a tradeoff at all, or who think that the root cause of all of this is just the developers being lazy.
If you're aware of the reason why Wireguard can't do updates while it's running, and you say, "that's fine, I still want to use it on Mac", that's a very different reaction than saying, "the devs don't know what they're doing."
I suspect that average nontechnical users are currently in the latter category rather than the former, but I could be wrong.
The smarter people will quit the Apple platform, and the dumber ones will quit the software whose creators refuse to put up with the Apple bullshit (plus some that try to put up with it but Apple arbitrarily fails their review anyway).
Perhaps it's an axiom that the open alternative is better in the long run, but that's too long a run to really care.
It's not the user's fault, bit it's the developer taking all the heat while it's business-as-usual for the reviewer.
I'm sure there's going to be some people annoyed just by reading that but if you dabbled just a bit into their ecosystem, you'll certainly know why I have this opinion.
I would vastly prefer to use Linux, but unfortunately that's just not an option for a company-issued machine at this juncture--and in my experience it's easier to spin up a VM on a Mac than a Windows box.
Being a Mac native dev, I'm very acutely aware of the pain other devs go through with Apple and their APIs, but unfortunately Macs remain a better platform to write code on in my personal experience.
But anyway I get keeping with familiar tools but, I just disagree that MacOS is a better or even "sane" terminal platform. All the ancient GNU tools Mac ships and BSD-style "but Posix!" pedantry drives me up the wall.
I have no desire to look at WSL ever again.
I experienced the same thing with on F# on mac a year or so ago, the dotnet CLI tool was effectively broken and official onboarding docs didn't work.
I tried revisiting when they announced F# 5 late last year, but same thing, docs don't work/broken on Mac. Turned me off for F# development and leaves me a bad impression on anything Microsoft releases.
You can explore the files stored inside wsl partition by going to \\wsl$ using file manager.
You can now also mount an external drive formatted as ext4 directly.
F# (and most of Dotnet core) is also a mess on linux, so no surprises here.
The files, for instance, were stored in NTFS but with Linux metadata in alternate data streams. Akin to what macOS used to call Resource Forks, except alternate data streams are far more rare in Windows and most native Windows apps trample over them. Microsoft didn't advertise where to find those files specifically because they didn't want people using Windows apps on those files and breaking Linux metadata. Instead, Microsoft heavily encouraged using /mnt/{drive letter}/normal/windows/path (like /mnt/c/users/me/Documents) and normal Windows paths and keeping files you worked on in both environments in the Windows plain old NTFS without alternate data stream weirdness side (because those /mnt drives didn't use the Linux metadata alternate data streams).
Eventually, Microsoft added a Plan9-based file server to WSL1 serving on the \\wsl$ system path for browsing those files and some smarts around it. (Launching a Windows EXE from a WSL terminal would convert the Linux path to the \\wsl$ path for instance.)
WSL2, on the other hand, is an extremely lightweight (Hyper-V based) VM, uses a real Linux kernel, and generally uses VM tech. Files are stored in a standard VHD, which can be explored with plenty of VM tools (including Windows File Explorer). They are still accessible in File Explorer through the \\wsl$ service. (Though in that case Windows can mount them using standard VHD mounting. The direction of the Plan9-based file server winds up reversed from WSL1 in that it is used instead by the VM to access host machine files through the VM barrier.)
As for F#, F# itself is an open source project with possibly a lot more of a "community project" mentality than it is an "official" Microsoft release. I don't know if that changes your opinion, but it is one of the projects where Microsoft has best embraced open source. (Including some of the potential downsides of open source, like needing Github Issues filed on broken documentation or it will go unnoticed/unfixed.)
I've been using git over 2 years on windows with no issues at all, it seems you have a buggy version?
The whole developers world would be up in arms if Git actually crashed in 1 out of 30 commands on Windows, _whatever the configuration, git bash, powershell, or WSL 1/2_. There would be yearly top hacker news post about "one year and still not fixed"
Heck, Git would not have reached its dominant position if it was such a buggy mess.
https://docs.microsoft.com/en-us/windows/dev-environment/ove...
Though who knows! Maybe I'll change my mind and get a new machine :)
Could you explain more?
I know installing and switching to WSL2 isn't as straightforward on windows stable. Is that what you are referring to?
If so, on insider - you can run wsl --install and it will work.
If not running wsl2 by default, wsl --set-default-version 2
I think they could make it easy to onboard users by setting better defaults and decreasing friction.
50/50 PEBKAC and Windows being difficult, IMO, but my total unfamiliarity with troubleshooting windows made the process a bit more annoying than I felt it ought to be.
I forced myself to work on Windows 10 Enterprise for a week and left kind of feeling OK about it. It's a bit slower than Linux, a bit too many moving things by default and I definitely prefer the env vars and config files over registry and control panel. But. I didn't use WSL or WSL2. I just had nushell and Microsoft's terminal app, with winget and all that. Some keyboard shortcuts and multiple desktops enabled, writing Rust software with emacs, firefox and a good terminal was not bad at all. I would not dislike working more in there, but in the end find Arch Linux to be the end game OS for me, so keeping the installation just when I need to debug some Windows issues.
Well, that’s on you. You could have had WSL2 which is amazing.
I jumped from XP to Windows 10 with WSL1 and had used Linux and macOS in between. It took me a few days to come across a bunch of pain points I was surprised had not changed; I do not like the install/uninstall scatter-shot method, monthly reboots for updates, control panels feel like archeology digging older UIs for settings, the window freezes and I cannot resize/minimize when the app is busy, I do not like Explorer or the windowing UI. PowerShell in practice seemed too verbose for interactive use and the learning curve/adoption was too steep to be productive (everyone else on the small team was writing BAT files). I got tripped up by odd things like offline documentation and you had to wrap it in a BAT file to automate it. I also don't like compiling stuff for Windows. I don't begrudge anyone who likes Windows, but I have a very strong preference for the other OSes. I might have some of those details wrong, but that's what I remember from the transition. I wished I had kept a diary because I forget a lot of it now.
WSL (admittedly v1) was a bit odd and hefty to install. The account/permissions and locations of files was awkward. I found myself ssh-ing into a Linux box to do a lot of things.
I occasionally look after a fairly large Windows WPF application which is half integrated with Microsoft Word and there are hundreds of lines of code dedicated to quite horrible workarounds for issues caused by API changes and weird ass behaviour. There are a lot of if statements for different Word versions as well.
For example: when saving a file "safely" (i.e. without weird ass side effects such as locking or document metadata corruption), if your word version is 7, 8, 9 or 10 you must use SaveAs2000 API call. If your word version is 11, 12 you must use SaveAs API call. If your word version is any other one then you need to use SaveAs2. This is entirely not documented past telling you that you are told not to call half of them and most of the reasons behind using them were discovered by taking the VSTO libraries to bits.
At the end of the day, the objective is to make sure the end user never sees the hell you had to go through and entirely takes your efforts for granted. They don't care and efforts to appeal to them are frowned upon, even if we whine and complain about it in our own circles.
With respect, then, you aren't making much of an effort to understand.
I admit, I was sometimes jealous of mac hardware, for example the new M1, magsafe, and etc (though not the terrible keyboards). Though I was never jealous of an iPhone's hardware. I was never ever jealous of the software. I always found it buggy and user-hostile.
The line you quoted was specifically about the user-hostility. You are using a machine that you can't control and actively fights you. It's mind boggling to me that developers agree to use such a system. Is this such an unreasonable opinion?
Just to give an example, it is quite easy to build Android apps in a CI, while iOS is a pain (specially because there is no way to build an iOS app in anything other than a Mac). Also, most bugs specific to a platform happens in iOS (they happen in Android too, but my experience is maybe 10 bugs in iOS for 1 in Android).
I control my Mac just fine. I've built tools from source; I run whatever I want; I can automate tasks I find tedious using the same shell tools available on Linux, and I still have access to MS Office (and no, open/FOSS "alternatives" don't work sufficiently well for me) and other COTS tools I depend on.
The Mac is absolutely the right platform for me, and I don't find it limiting or broken or hostile AT ALL. And neither do millions of other folks.
I also work regularly with Windows, and have a higher-end Dell XPS on my desk for that purpose. Windows is so profoundly broken and un-discoverable and inconsistent (not to mention unstable over time) that I cannot fathom choosing to use it over anything else -- and it's the only OTHER platform where I could get access to some of the tools I rely on. Linux isn't there, and hacks to try to make things like Win software run there imply a level of tedious fiddling that I'm 100% retired from.
>Is this such an unreasonable opinion?
I guess it depends on whether you consider an unstudied, single-POV opinion reasonable.
Someone should start an Apple developer support group on appledevsupport.group or something and get users to upvote broken API's (and broken terms of service: like mentioning donations are accepted in a free app!) that need fixing. Getting enough developers in one place to embarrass them might be the only way to make Apple care.
Filing onerous radar reports to help Apple is not my job.
But I haven't seen a "well documented" one either. There's a lot of arcane knowledge in targeting MacOS.
Second, this has significantly tempered my lusting over the new M1 macs. I think I can be content with my ThinkPad's running Linux.
not optional and requires special app entitlements to enable. So you are not going to write portable code that has a JIT without apple-special code.
If you supported an older platform (High Sierra, which up until recently was... valid...), you would need to explicitly _not_ pass MAP_JIT into mmap there. It makes total sense once you find the bug, but it was also an easy one to overlook.
Tracking that down was kind of annoying.
Felt like an enourmous waste of money and time.
And it certainly was. But sometimes you have well-appreciated macOS users that you have not yet managed to convert out of it. In that case, instead of throwing away your money you can easily [0] install a Catalina vm inside linux or windows. With a quite small effort, you can readily check that your program compiles and runs on that shitty system.
It is like downloading binary freeware.
The ToS are a separate issue, but I doubt they'd hold in Europe for example.
Bringing in words like "illegal" can be fraught because I don't think we've seen a court case (in the US at least) about exactly how binding a "click-wrap" agreement actually is, but there's no question that projects like the one linked upthread violate the terms of the software license.
At least you can XCode working and do macOS builds.
Spent another weekend moving my wife over to a new Windows machine ... not interested in that environment.
Apple's core strategic weakness is being the dominant market participant for too long. It is as if hardwired into their corporate cultural DNA is the absolute need to be the underdog. Once they dominate for awhile, they start seeking out easy answers, and it takes strong leadership that demands finesse, class and taste in solutions to steer them past the answers within their immediate grasp, and uncomfortably reach for the ones that pleasingly engage customers. This starts with their relationships with partners, then developers, then customers, then it corrupts their products, in roughly that order within their overall ecosystem. We have another decade or two to go before it gets that bad, if it gets that bad (I really hope I'm wrong, their corporate culture otherwise from a customer perspective is highly desirable).
I'm getting out while the getting is still good and migration paths are not quite so painful. Part of this is because the raw hardware capabilities of my dual-track alternative (Dell Precision 5500 fully tricked-out) are a quantum leap over Apple's offerings. I have simultaneously put up with non-Apple trackpads, keyboards and OS's on Wintel laptops I simultaneously carry (hazard of consulting) while my main daily driver is an Apple, so those don't faze me.
There was a brief, glorious period in the 00's when Apple locked in users by being a superlative superset of delighting capabilities above Wintel gear that compelled users like me to share with those who asked me about my quirky non-enterprise choice in the enterprise consulting space, "I use a Mac because it is a very good mobile Unix slab", and they came away impressed and agreeing with the choice, "if only we had the money". As a consultant, I got a pass for having the money to make that choice. Mac laptops for a brief 2-3 years had the densest memory, mass storage and top-of-the-line mobile chipsets, making many light "server-like" tasks upon it feasible. I heavily leveraged those capabilities to run rings around other consultants, able to deliver results in a fraction of the time because while they were requisitioning servers, I was already coding, debugging and running tests. Haven't had that experience since.
I'm hoping I can catch some of that fire again with a Lintel setup. The general lack of developer infrastructure discipline I see across the board is leading many corporate cloud environments to enshroud themselves with all sorts of cost containment approval procedures, and most of my clients have already lost the agility cloud promised. Better security postures within my clients' sites also makes it increasingly difficult to access my own cloud accounts. So my own development deck once again makes sense for my own specific use case.
I'm not trying to carry water for Apple here but what types of development are you talking about that won't be able to continue on the M1? Sure a lot of stuff wasn't there at launch but it looks like even docker (which was speculated to take a long time to get working) is getting close to a solution for arm and x86 containers to run on the M1. Brew is another one that wasn't ready at launch but my guess is that within a year or so the M1 (or it's successors) will be nearly identical to my current dev setup (which is one reason I'm waiting for the dust to settle).
Are there any developers who aren't?
>this has significantly tempered my lusting over the new M1 macs.
What sad is that when it comes to locking down computing devices Apple really is the vanguard of where things are going.
Apple makes big money from their ecosystem. Wireguard developer provides high-quality solution for free, helping to grow proprietary ecosystem, essentially helping Apple to make more money indirectly and directly (by giving 30% from donations).
In return developer gets tons of hate from users and from Apple itself in the form of delayed reviews, rejects and constant threat of violating some rule and getting dev account banned.
In my opinion, the only solution for this is to stop providing services for free and put a price tag on the app.
I understand, that developer is a kind, not-yet-burnt-out person who wants to be the world a better place by providing the free way to exchange information securely, but doing so for free for corporate ecosystem is clearly not sustainable, neither financially nor emotionally.
That's one of the more annoying parts about Apple being the gatekeeper to 40% of the US population (and in effect, to 100% of businesses). As a developer, you are just stuck with no way out.
In WireGuard's case it's maybe less obvious than messaging, but if WireGuard doesn't work on macOS, it's enough to have one Apple user in your whole organisation in order to make it a non-viable solution.
Additionally, companies don't choose their whole software stack based on their VPN solution. They would just change a VPN solution if it's incompatible with what's there.
By now, video editors and sound mixers are heavy windows users, because there's no halfway endurable Apple machine that you can purchase that supports 128GB of RAM and 8+ CPU cores and NVIDIA CUDA. Because like it or not, almost all video editing plugins use CUDA for acceleration.
https://avid.secure.force.com/pkb/articles/download/Pro-Tool...
The industry standard for movie mixing supports: macOS Catalina (10.15.7), macOS Mojave (10.14.6), and High Sierra (10.13.6).
In other words, they didn't even bother with Big Sur yet.
Source? This is not reflected in any of the studios I know.
And yes, the users are smart enough to see there’s an iOS client so you can’t just tell them “it’s not available”.
So if bigcorp wants OS X WireGuard support, they should be able to pay handsomely for it.
If they aren't willing to pay, then I believe the project should just avoid offering it, to avoid getting burnt out from unreasonable requests.
Who says they're not? A lot of the companies on https://www.wireguard.com/donations/ ship their own macOS software. Just because the Wireguard Mac app is free doesn't mean nobody's giving them money that's earmarked for Apple development.
Apple and Apple users respond to tangible consequences; appeasement doesn't seem to be working, and it doesn't seem to be benefiting the project either. Like OP said, it's magnanimous of the developer to do this but I don't think "users demand it" is a great justification, nor is it quite in the spirit of open source.
Edit: I should add that there is another cost/benefit assessment here: if Wireguard developers continue to appease Apple, Apple will continue to make life difficult for them as there will be no pressure for it to behave better.
See:
> We faced rejections in submitting the app, because they decided to change their policy on the app having a link in the "About WireGuard" tool window to www.wireguard.com/donations/ (which they previously had allowed explicitly; now they want 30% or something)
In my day job, our Apple developers have spent years finding solutions to iOS restrictions around CallKit, Push Notifications and NSTodaysProblem, and those are just the things Apple has intentionally restricted, once you get into the bugs and poor documentation for some APIs it's another story.
If our users knew the half of what our Apple Developers have to do, the meetings, discussions, concessions and re-design that has to be done to make things just work, even on par with the Android equivalent, they might be a little bit more understanding.
WireGuard has been excellent, and as a Linux user, I haven't needed an app, I have a couple of aliases in my shell to start and stop my tunnels. I've used WireGuard daily for work since lockdown and I used it daily for personal use, while commuting to work before lockdown. In all of that time, I've never had a single issue due to WireGuard (and there isn't even a Linux app to be seen). The expectation is often different between Linux and Apple users though.
When I was setting up for the first time, Jason even found time to help me himself on the IRC channel, something I've never expected, and for which I am eternally grateful.
I made a donation to WireGuard last year, I'll be doing the same this year and I encourage others to "put their money where their mouth is" and show a little support for the people making and sharing this software for free. I expect an Apple user can afford a small cut of their or their employer's money to do so.
Eh? Isn't that a description of the original complaint, and the 'a response' submitted here is from WireGuard creator/lead Jason/zx2c4 explaining much as you do the restrictions, bugs, and limitations he's tried to work around?
By "response" I meant the response of the user to the WireGuard Mac app.
Again apologies, I somehow jumped a few mental hoops of my own when commenting.
What about the problems? Well, it's free. They owe me nothing. But, you should still be aware what you are getting into when you choose to [use the app]. That's why I wrote this post: to serve as a warning to others. Let my frustration save you the same in the future.
When it comes to WireGuard, just stick with the tried and true low-level Unix approach, even on your Macs. Your sanity will thank you.
I just hope the iOS version never flips out on me.
Anyone who has a problem with that state of affairs has a beef with Apple, and should not be posting their displeasure to the WireGuard mailing list.
It's not that Apple doesn't budge, if people shout loud enough; their Push/APNS change deadline was pushed back twice, it can happen again if enough people push enough for them to start treating their 3rd party developers like first class citizens.
What bothers me is that I’ve experienced an increasing number of maintainers of supposed cross platform projects simply not care about macOS anymore to the extent that they’re openly hostile towards macOS users. I know what you do is free and I have no entitlement to anything from you, but don't antagonize me when I add suggestions to open discussion and feature requests to your issue tracker to try and help participate in improving the way your project works on macOS. I’m probably willing to do some work but also need to get the lay of the land first.
I would challenge those maintainers to be honest. Yes, it’s your time, but if you’re not interested in spending it actually supporting macOS, don't market your project as a cross platform. Like it or not the macOS platform is changing and if you’re not along for the ride don’t grief everyone who is (either by choice or by requirement).
Just to be crystal clear: Json does not fall in this bucket, but this topic in general seems all too familiar lately.
There is lots of cross-platform software, which works on Linux, Windows and even BSDs; you can't expect (or feel entitled for) open source maintainers to then also go ahead and buy expensive Apple hardware just to support their idiosyncratic almost-BSD-but-not-really-UNIX OS.
How I finally solved this is I got a Mac Mini from cloud, I could with a lots of trouble finally start docker in it (needed a desktop to click some icons) and test my code. This meant statically linking OpenSSL instead, which is not the greatest from a security point of view.
All of this took six months, and it was really hard to get Mac users to commit anything. It was ridiculously annoying to write and test without buying an Apple computer.
After this experience I just don't want to support any of their products anymore. Too much time wasted.
There are absolutely OSS maintainers who wouldn't mind patching things for macOS... if they could figure out the expected behavior/etc. I've fixed things for projects that I only know about from plumbing around in AppKit for a few years now.
There is a lot of graphic design and video professionals that will jump the ship. We have Blender, and Resolve is working under Linux, but Inkscape and Gimp are not capable enough to replace Sketch/Affinity/Adobe Illustrator/Photoshop.
This is not a conspiracy. This is the official plan for the 4th industrial revolution by WEF. (https://tinyurl.com/yyfmj7gk). The goal is to abolish private property and live in a real time data driven world which is clearly a Communistic Agenda "The theory of the communists may be summed up in the single sentence: Abolition of private property." - Karl Marx.
In this context big corporations are cooperating with governments under supervision of WEF to implement general control with global AI infrastructure (actually there is EU program for supercomputers network already in place). Apple, Google, Microsoft and Amazon are part of this network of influence and they will sell user data to governments on demand.
The idea of personal computing without authorisation(Digital ID https://tinyurl.com/y5he2qr9) and oversight (telemetry) will be contrary to the values of the new Digital Utopia. Obviously big tech is politically driven and will be protected from scrutiny in the future in this context.
Literature: "A Framework for Developing a National Artificial Intelligence Strategy" - WEF link - (https://tinyurl.com/y6lwfdcy).
In practice if the MacOS support takes more than a quick headers / types update, it will likely need more care in the future as well. That means you need not just a driveby fix, but a continued commitment from someone to ensure compatibility. This is not out of hostility towards the users, but I'll keep calling things that don't work on MacOS cross-platform. (Yes, it sucks; You can vote with your money to stop that situation)
Some stuff can be built for Macs from Linux, stuff like the Godot game engine supports this.
It is however a guess if they're going to allow that build or not.
Not even that; I've developed for Windows using Wine plus a mingw cross-compiler packaged by the Linux distribution I was using. Another alternative would be ReactOS in a VM.
For what it's worth there are many "click and run" virtual machine creators for OS X. It's not acceptable for corporate use because of the license violations, but to be honest I see very little issue for open source developers using such a solution if they don't have a Mac.
I think this is the key insight. I tried to do a similar thing with Windows. The free VM expired every 30 days or so and bootstrapping a build environment each time (even just downloading it) sucked. The build environment is an outlier compared to macOS/Linux/Unix. I eventually ended up paying for Windows. I still couldn't test things like OpenGL inside a VM.
So blame Apple for it - why do you blame the developers?
Apple wants you to forget that it is the developers that add value to a platform, and yet it charges them for the "privilege" of creating apps for their platform. And then they are openly and increasingly hostile to developers who do not conform to their business model and do not want to pay them or distribute the app through their app store - and thus they keep crippling API after API to make sure that the developers toe their line.
It is because of Apple's hostile attitude to developers that they no longer want to invest (or rather waste) their time on Apple platform.
Here's a real life example of an app that is now no longer viable on macOS because it doesn't suit Apple's goals - https://medium.com/tripmode/apple-started-hiding-the-traffic... ...
If they can't change X because it will screw over critical application group Y, then developers can complain as much as they want until they have some practical way to deal with that. If they were constantly screwing over Y, where Y was different depending on the problem, they could eventually screw up all of the apps, users, and developers.
Apple isn’t feeling the heat for the dumb decisions they make with their platform, users are because they get berated as idiots for ever owning an Apple device by frustrated maintainers.
I mean I’ve seen things like “the problem is not the $99 developer fee, it’s paying it to Apple”. If that’s how you feel then my offer to cover the fee so your project can publish notarized releases isn't going to go anywhere and your project wont ever properly support macOS. Sorry.
That is ironic, since for years I have seen "Cross Platform" to mean Win + Mac, and exclude linux users.
now that is Win + Lin due to how hostile the Apple Ecosystem is to anything "not invented by apple" and you want to blame the open source devs for that...
Then I was rudely accused of not using cmake, when autotools perfectly support cross builds (better than cmake on Linux).
It is not my problem if a purported Unix does not ship gcc or if clang cross builds are painful. Go and install gcc!
If Apple were interested in being supported, they'd fix their tool chain and provide free testing infrastructure to OSS developers.
This is not bothering. This is a very fortunate situation. I hope this process happens faster!
What I don't understand is your point of view. It is not these sane developers who are "hostile" towards users. It is Apple who is callously hostile towards users and developers. By degrading the macOS experience, these developers are making the world a better place.
I help out on an open source emulator/game project and wound up becoming the de-facto "Mac guy". I don't mind it, but I do find myself annoyed with the people who deride the platform for not being either Windows or Linux.
Just went to donate for myself, and happened to spot Rachel’s name in the list of donors too, so that’s a nice little end to the story :)
(Not as nice as “apple either fixes their APIs or permits people to work around them”, but still...)
It's frustrating, but it's also great job security.
Imagine, Apple even wanted 30% of any donations!!
> We faced rejections in submitting the app, because they decided to change their policy on the app having a link in the "About WireGuard" tool window to www.wireguard.com/donations/ (which they previously had allowed explicitly; now they want 30% or something), and then after removing that ... Well, finally they approved the fix ...
Nothing Jason from WireGuard wrote invalidates anything that the original blogger wrote. The Mac App sucks and Jason merely explained why. In other words, both Jason and Rachel are correct.
https://rachelbythebay.com/w/2020/12/24/wg/
Personally I rarely use a mac, and don't do wg on demand, but one thing that did annoy me was being unable to set dns search domain, which wasn't mentioned in the blog post, but I believe is also caused by OSX deficiencies.
That lets you route the resolution of particular domains to specified nameservers. The files live in /etc/resolver but can also be manipulated with scutil.
So it's not an OSX deficiency, it's an OSX difference, similar to launchd vs systemd.
I can do this on the OSX networking tab where I set DNS server, but from what I read that feature isn't available for the wireguard client.
No one company can uniformly manage so much code and hardware to boot and do it perfectly. There are things Apple could do to make it less irritating—the hard problem is picking which subset of horrifically irritating things to fix.
Louis Rossmann would disagree
Not only is it much faster other VPNs that I used in the past, but compared to other clients (Forticlient and Tunnelblick), the overall experience feels much nicer, IMO.
Thank you so much for your work!
IPSec is as fast as Wireguard. And there is native client in MacOS. As for bloated codebase, there is an OpenBSD iked rewrite.
On MacOS you can use Apple Configurator /Apple Profile Manager and on Windows Powershell, to configure stronger security.
The nice thing with WireGuard is it’s either secure or it’s off.
As you say, it’s easy to misconfigure IPSec and the number of experts gets smaller day by day.
- multiple users on the same machine cannot have their own credentials for the same tunnel; you have to create several tunnels and each user sees all of them. Obviously, you cannot save password then.
- if you want to setup routing for your L2TP split-tunel, you have to create bash scripts (ip-up, ip-down) in /etc/ppp. Not even Linux makes you to do this by hand.
Compared to this, Wireguard for Mac is much more polished.
Otherwise, a good question for Ubiquity, why they don't support IKEv2 (among other things), when they are using strongswan underneath anyway.
However, I've had issues since I upgraded to Big Sur. I can't edit my tunnels anymore.
And even though it was Christmas Eve you send it off partially in disgust and partially in a “maybe this explanation makes it clear”.
The response is much nicer than deserved. I would not have blamed him for a less friendly reaction.
It’s also true of much enterprise software - it’s often as good as the developers could make it given the constraints they were working with.
It's been kind of a weird transition. I was talking to someone recently about accessibility between multiple GUI frameworks (QT/Electron/GTK/Swift/etc...) and they brought up Mac accessibility differences. And immediately my brain jumped to, "well, who cares if those frameworks are accessible on Mac, because it's not like my software is going to be on there. Only the Linux/Windows/mobile experiences matter." It was a very strange feeling to have that be the first thing that instinctively popped into my head.
And I'm only one developer, and probably no one's really going to notice or care about my decisions, and historically as long as users demand Mac software/releases, developers have had to just put up with it, so I don't have strong evidence that this is going to be different.
But I wonder how long that can hold out before eventually something snaps. Realistically, there's no way that Wireguard can refuse to release for MacOS. But everyone else? If you're making a game, why would you ever target a Mac build if you're worried about running into issues like this? Is the gaming marketshare on Mac really big enough to justify this kind of annoyance and time commitment?
I'm probably naive, but it just seems like at some point developers are going to decide that the only reason to support Mac is if it's their primary market. Maybe Apple doesn't care, maybe they'd like us all to move to iOS anyway.
[1]: reader decide whether it is a good solution or not
This is one of the things I dislike most about Apple: even despite the high price I pay for their products and (subsequently) the astronomical profits they make, somehow they seem to be completely unable to simply address these kinds of problems as soon as they pop up and make everyone happy again. It's also in Apple's own interest to make sure VPN extensions can automatically update in case of potential security problems, no? So why they don't just throw enough resources at it to make it work really is beyond me.
There's a lot to like about Apple products but their culture towards addressing problems that affect their paying customers is becoming increasingly off-putting, especially since they have basically been printing money for over ~10 years now and have no excuses to not improve these kinds of things.
Apple can't hire enough devs.
I told an SWE friend of mine at Apple that I wouldn't mind working there - then he explained to me how restrictive it is to work at Apple (e.g. you have to close your GitHub account, you can't do any moonlighting or FOSS contributions: even on your own time, on your own hardware, while on vacation) - I can't work at a place that wants to exert that much control over my personal life. I get that secrecy is part of being an Apple, but it feels the same as how I thought it'd be cool to work for the FBI's infosec team before I learned that they have mandatory regular drug-testing even for employees in states where cannabis is legal.
Apple decided to not hire more.
Apple Inc. has massive profits and they apparently decided that frameworks are good enough and it is not worth to pay more (both in cash - and also indirectly, by less hostile requirements).
Apple's overly protective threat modelling/mitigation is a selling point and not a "flex" for me.
One rule for small, other rule for big.
https://developer.apple.com/documentation/bundleresources/en...
It's under "Discussion".
Haven't tried out if it works though, but the link in [6] that the developer refers to is 3 years old, so maybe check again?
No, not so. Plenty of VPN apps based on network extensions are delivered outside the Mac App Store. In fact, most commercial VPNs are done this way. My company uses GlobalProtect for example, and I can install it any number of ways, and it’s been NE based for over a year now...
> When I'm debugging these issues, I'll often times spend a few hours in IDA Pro (Apple doesn't provide debug symbols, unlike Microsoft, which makes this process even more miserable than it already is), and after identifying the issue I'll often have several ideas for "clever" workarounds. Which of them are acceptable for the App Store? Usually none!
Really, why we need to have very talented people spending their time in dealing with this, instead of contributing actual value on other parts of the project? Apple should be losing devs in favor of other better platforms, not the other way around. With less and worse products at their disposal, Apple users would then be well aware that they are choosing a platform that alienates developers.
Change is the only constant and I've learned to embrace it where possible or suffer later.
What is claimed to be backwards compatibility is only partially true; reality is that bugs and their workarounds will exist forever.
As for Linux and breaking userspace, that's the kernel interface which is stable, not the whole distribution. I really wish people would report that honestly. NT's API is stable too. It doesn't mean Gtk and ComCtl32 doesn't have abhorrent stability problems and bugs in them.
The issue is, on all platforms, the thousands of libraries each containing hundreds of calls and data structures.
[0]: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
Developing for Windows back in the day, it was about halfway there. I had zero ability to communicate back to the platform owners, but I rarely if ever felt shit on, disrespected or disregarded. In contrast, on Win32, I felt like everything I wanted to do had already been considered ahead of time, thought through, and there was an existing and elegant solution available.
If you buy your stuff used that's fine IMO.
The number of people who gate a mac purchase on the capability to speak WireGuard is tiny.
I now only connect my macs and ios devices to the internet via external VPN router/firewalls on which I have root; I can no longer invest the time to hack macOS sufficiently to permit me to ensure that no unauthorized traffic is leaving it.
This means none of my iPads or iPhones have SIMs in them any longer, as I take this approach even when mobile (gl.inet makes a travel VPN router with an LTE interface that runs OpenWRT).
My guess would rather be that Apple at some point cared about corporate VPNs but no longer do, and that option is mainly just legacy.
> This means none of my iPads or iPhones have SIMs in them any longer
If you use Apple products for personal use: you sound like a masochist.
If you are forced to use them professionally: I'm sorry for you.
I bought my android phone for less than 150€ and it does what I need (phone calls, navigation). For everything else I use a debian based distro on my laptop (in some rare case, I dual boot windows).
I really have no issues and I spent way way less than any Apple fan ever will to do basically the same thing.
Let's be honest, most people are willing to pay hefty prices for Apple's products just because of the social status they provide.
I can't justify wasting that much time and stress on a platform that clearly is more concerned with meeting the needs of casual users and media professionals rather than developers or those concerned with freedom, security, or privacy.
It’s because Apple prioritizes users over developers that they have so many users.
Probably it just seems bigger here in Hacker News where most of Apple users are also developers...
So far, good hardware, close-to-*ix-OS software, and penetration are kind of make them a hard competitor to beat.
What other "better" platforms are you thinking about?
Edit: and don't forget that ElementaryOS gets you pretty damned close to the Mac UI experience. I personally prefer GNOME, which seemingly steals inspiration from across the industry, so it's different but also really slick (the use of Super/Winkey as both alt-tab and the launcher is genius).
I like the thicker case as well. The mac just feels too flimsy when I'm banging away on the keyboard.
personally, I've been really enjoying the Thinkpad 14s AMD - 8 core / 16 thread / 32gb of ram in under 3lbs, shame about the screen though.
Second best is Dell[0], I have used two generations of their Ubuntu-oriented XPS 13 or Precision laptops. They're fantastic.
[0] - https://www.dell.com/en-us/work/shop/overview/cp/linuxsystem...
As for myself, I work on Linux systems, so my preferred platform would be a beefy PC with some Linux distro.
Yes, Apple makes good hardware. Or, at least lets say they worked hard on creating a distinctive perception about their quality on the consumer's minds. On the other hand, for some reason people tend to avoid spending similar amounts of money in the other ecosystems (or that's what I feel in my circles). I mean, try spending the same money that you would pay for the latest iPhone or Macbook, and you will get a fabulously spec'd Android phone or laptop.
Windows? Microsoft hate and distrust aside, they are a company founded for Developers, by Developers and in general the "Developers, Developers, Developers" mantra still resonates through the halls and they try to make life easy as they can for developers. (They publish debugging symbols of the entire OS just about, as a specifically referenced point elsewhere in this thread, which affected the specific complaints of the article. Even all of the "developer unfriendly" complaints about their more recent platforms/SDKs/toolkits have mostly been walked back or are still in the process of evolving.) Just as with Linux systems, plenty of good hardware exists even if it is harder to find. WSL1 and WSL2 provide a bunch of options for how "close to *ix" you want to get. It's hard to beat Windows on penetration, because it is still the majority OS for most of the mainstream world.
Windows has decades of cruft and the OS itself is basically adware at this point with "recommendations" and shit showing up constantly, un-removable foistware, dark patterns to herd you into MS cloud, and loads of gratuitous telemetry. Windows drivers, driver signing, and installers are all horrors that can reduce one to a gibbering lunatic like the poor souls in Lovecraft's fiction. Networking is horrific too, and NTFS is slow.
Linux has fragmentation, fragmentation, fragmentation. There are at least three package formats, two or three inits (though I think we're converging on systemd in spite of its many warts), and loads of gratuitous distributions and sub-distributions and spins of distributions that have no reason to exist except for some minor holy war over some minutia or license holy wars. Oh and the most popular package formats, dpkg and RPM, are arcane nightmares from the pit of hell.
Every time I get mad at Apple I try working with another platform and realize Apple is not that bad. They all suck.
Do they want a closed platform? Let's give it to them. Stop developing FOSS for Apple. It's a "market share" I'll happily give up (and I did already).
Neither of these are the actual title, so that can't be the rule it was operating under, and the fact that it's a developer (as opposed to some other user or Apple/Wireguard fanboy/hater) does change the context, at least for me.
Cisco doesn't host their VPN packages on the MAS either.
It would be fine if these complaints about old details were reported to developers as “blocking any future app releases”, but blocking immediate bug fixes really hurts.
Jason implies that Mac apps that use the Network Extension can only be distributed through the App Store, but this appears to be a misunderstanding. This page at Apple purports to document a way to build an app for distribution outside the App Store:
https://developer.apple.com/documentation/bundleresources/en...
Perhaps this would allow WireGuard to support the Mac more easily without having to rely on the App Store. (It still requires an Apple Developer account, but that's already a requirement for the App Store.)
If this has changed for the better, it has changed very recently.
Do not skip the Mac app. It's pretty good.
I haven't had any issues with the Mac app, but for where the app may be lacking because of the circus that is developing with Apples frameworks and app store it makes up in being absolutely amazing behind the scenes.
All the other solutions I've tried have taken weeks of learning and tweaking configs. Had the entire WireGuard solution going end to end in a few hours.
It's super simple, lightweight, reliable and easy to understand.
It's a shame Apples app store policies and being forced to work with buggy frameworks is holding back developers abilities to write first class native software for MacOS.
Dumb question 2: Why isn't it a good idea to create a non-profit, or distribute via a partner non-profit, to reduce the App Store take to 0%? (Even without that, Apple's take would be 15% until the app hits $1 million in annual net sales there.)
I see people in the thread asking for special treatment for this (important and worthy, of course) project, which Apple obviously can't do that without creating a thousand other problems.
On the off chance this post is read, the bug report is simple: WireGuard for Mac doesn't respect /etc/hosts.
In which case, only apps like parallels would have to be working, then the bugs of macOS could be bypassed for many and focused for a set of well-funded developers.
All apps would have a translation layer, but that seems to not be an issue with the m1.
If I want to donate to a project I want to browse the site and learn more about rather than straight to the donation page. Seems like a money grab to take me to the donation page.
What Apple needs is a curated system to support open source development for apps - for example, after proving that you really are a non-profit (think Mozilla foundation) Apple could still charge the 30% but then rebate 20% back as a donation from Apple itself. Win/win.
3.2 Other Business Model Issues [..] (vi) Approved nonprofits may fundraise directly within their own apps or third-party apps, provided those fundraising campaigns adhere to all App Review Guidelines and offer Apple Pay support. These apps must disclose how the funds will be used, abide by all required local and federal laws, and ensure appropriate tax receipts are available to donors. Additional information shall be provided to App Review upon request. Nonprofit platforms that connect donors to other nonprofits must ensure that every nonprofit listed in the app has also gone through the nonprofit approval process. Learn more about becoming an approved nonprofit. [https://developer.apple.com/apple-pay/nonprofits/]
Mozilla Foundation would be fine, but WireGuard is in hot mess as the "Donation" is not actually going to a non-profit organisation - it has in fact taken steps to avoid identifying _who_ the money is going to.
There is no misleading link. It's only a "Donation" button on the About window that opens a hyperlink, similar to this one [0]. How is it supposed to be a money grab? TBH, I don't think anyone ever bother to click it to begin with...
Wait, are there people reading random blog post about piece of software and deciding it would be a good idea to nag author of the software by retranslating someone other's opinion? Isn't that, how to say, inadequate?
As a developer, I usually find it rewarding to work with the Sandbox and not against it. Making this part of the product conception very early on results in much smoother experience at the end. Of course, if submitting to the store is an afterthought there are surely some challenges to tackle.
Thanks for the laugh! "Apple has restricted" usually means Apple wants to retain complete control in order to extract maximum profit. That's all it is.
Isn't this what code comments should be good for preventing?
Anyway, no software development process is perfect, but sure the Apple ecosystem make everything worse.
> I should have caught it, and I take responsibility for it, and probably workarounds need more comments so this doesn't happen
Apple is predatory white-washed garbage.
They can't.
WireGuard Developer Response to "Great protocol, skip the Mac app" blogpost
Note that it is currently 1:33 AM on the west coast, so they may not see it for a number of hours.
Wireguard is using the newer and non-deprecated NetworkExtension framework which requires an entitlement that's only given to app-store apps.
Apple's going to have trouble if they keep on hindering the people that made their platform and support their ecosystem.
Apple is not living up to their "Think Different" ethos: http://www.thecrazyones.it/spot-en.html
Apple in 1997:
Here's to the crazy ones.
The misfits.
The rebels.
The troublemakers.
The round pegs in the square holes.
They're not fond of rules.
And they have no respect for the status quo.
> Follow our poorly-explained, underdocumented, and arbitrarily applied rules or we'll ban you from the App Store.
they are though. It's getting harder and harder to get them loaded (on an M1 Mac, getting an extension loaded will require 4 reboots and a journey through the recovery environment).
I'd say that within the next 2-3 macOS releases, kernel extension won't be loaded at all any more and only user-space APIs will be available for third-parties (including drivers).
From a security perspective, this is a huge benefit to users of course, but I agree that at least for advanced users, the ability to patch the kernel at random would still be beneficial for some use-cases.
iOS is far more restricted in this regard — for instance, writing a driver for your USB HID device isn’t possible there, but it is on macOS, and that capability isn’t disappearing. I don’t think iOS has any of the new virtualization APIs added in Big Sur, either.
That said, the userspace APIs need to be made much more robust before kexts are deprecated, and so to me that is what Apple should be pressured to do. Kernel extensions should be a last resort, not the go-to solution, because the reality is that they’re a security nightmare and have been readily abused (remember the mess with Dropbox of all things installing a kext?)
It is possible through the "MFi" (Made for iPod/iPhone) programme: that's how custom iPhone accessories that use the Lightning port work: they get to write their own user-mode driver for the USB port. Ditto for "Classic" Bluetooth devices.
Similar to ios - you can't install any kernel extensions to it without Apple's special permission, and have to do everything with whatever API they have implemented snd exposed.
(In macOS's case crippled APIs with backdoors - e.g. application firewalls that use these new API cannot block some Apple apps.)
> I don’t think iOS has any of the new virtualization APIs added in Big Sur, either.
It will - Apple is moving both ios and macOS towards the same goal of converging them into one product. We saw that with multi-tasking advancement and other features in ios with iPad Pro's, and the crippling of macOS from Catalina onwards.
hardware accelerated operations will be covered by whatever drivers ship with the OS or can be written by DriverKit.
The times when Photoshop has required kernel extensions to be loaded are long gone. The UX around kernel extensions has been very bad for years already (granted - just a trip to the system preferences, but still), so Adobe really couldn't afford such requirements already.
Have you seen what Apple's been doing for the last few years? They don't care if your app or workflow breaks. If you make enough money on your app, you'll jump through any hoops they prepare.