> You pay tax direct as us residents, or as tariff if you are in rest of world.
Tariffs on goods coming into the US are paid by US residents. (Just had to pay customs to clear a shipment from the UK - I had to pay the tariffs, not the seller.)
> Things are moving ridiculously fast for government to the point I suspect there was alot of desire to get rid of all this stuff before, but people were unable to do so.
Assuming "was alot of desire" is meant as "widespread support," not just "the President really desired it," that is an absolutely ridiculous interpretation. Fast does not mean strong consensus.
The government has also moved _ridiculously fast_ to
- pardon/commute the vast majority of J6 defendants including those convicted of violence towards law enforcement
- freeze federal aid across the board
- blame the recent aviation crash on DEI
- rename the Gulf of Mexico to Gulf of America
- revoke birthright citizenship
Does that mean that there "was alot of desire" to do those things? Absolutely not. It just means that those are things that the President has done unilaterally via executive orders or press release.
To be clear I'm not advocating for or against the govt.
But the idea that the government moving "ridiculously fast" is because there "was alot of desire" is a massive stretch. They are moving fast because they are steamrolling everyone in their path (allies included), and in their desire to "get shit done" they are implementing changes that are riddled with errors, and in some cases, even flat out illegal.
> Sega might claim that they have only licensed them and you don't own them; a court might disagree, given the big "buy" button and the consideration paid for them.
I'd really like to believe that is the case, but I think we've already seen that is generally not true based on other digital marketplaces (e.g. Kindle books, iTunes media, etc.)
But specifically regarding Steam... this was just last month[0][1]
> Valve is now explicitly disclosing that you don’t own the games you buy from its Steam online store. The company has added a note on the payment checkout screen stating that “a purchase of a digital product grants a license for the product on Steam,” as reported earlier by Engadget.
>
> ...
>
> Why? Probably, a new law. California has a law going into effect next year that’ll require digital storefronts like Valve’s Steam platform to clearly say that you’re only purchasing a license for your digital media because some companies like Ubisoft and PlayStation were removing digital purchases from users’ libraries, keeping them from playing games like The Crew or watching their old Discovery shows.
> 1Password 8 requires iOS 15, so the updates that you're paying for as part of your subscription model require that you pay for a new phone to get them.
That assumes that iOS 15 requires a new phone... which isn't the case. Apple generally has an excellent track record of supporting older devices when they release new major OS versions.
Taking a look at the devices that support iOS 15[0], the oldest one appears to be the iPhone 6S... which was released in 2015. So you could theoretically use the new 1Password 8 on iOS 15 on a phone that is 7 years old. No need to pay for a new phone.
A little surprised no one has mentioned OmniGroup's [0] applications.
Some of their applications (e.g. OmniFocus) support syncing online via an Omni account, but also offer support for syncing to a custom WebDAV server[1]. I run my own WebDAV server and point the macOS and iOS apps at it.
> Did you notice that we wrote a detailed documentation page about how to report those metrics to any service of your choice?
Perhaps you should link that on the Analytics[0] page instead of directing users to contact the sales team for more information on non-Vercel deployments.
> I've been generally happy with Time Machine's stability, but this is getting me a little worried.
For the longest time, I backed up my MacBooks with Time Machine to a NAS.
Seemed to work fine - Time Machine was successful and I was able to browse previous versions on the machine being backed up without an issue (browse history of machine A on machine A).
Then one day I was planning to wipe a MacBook and do a clean install - figured I'd confirm I could browse my backups made on machine A on machine B before I wiped A. I spent over an hour attempting to open the sparse bundle (w/ Time Machine and manually) and just couldn't do it - kept loading forever or giving me errors about volume verification among other things[0].
> I guess now's a good time to looking into Arq (or similar)
Like you, I decided to take a look at alternatives. I'd previously played around with Arq (v5) and it looked awesome - stable, well-documented, etc. Well, by the time I actually needed an alternative to Time Machine, Arq had released v6 - earlier this year[1].
Unfortunately it appeared to be bug-prone (not great for backups!) and lacked ANY documentation (one of the great things about v5 was the in-depth documentation, particularly around backup format). Users on the subreddit[2] weren't thrilled and you can't purchase v5 licenses (and TBH I wouldn't recommend purchasing software that isn't supported anymore).
Within the last week or two, Arq has released a second major version within a year - v7[3]. Feedback appears to be better, and the author has acknowledged mistakes, but TBH I'm wary. Definitely not adopting two-week old software as my primary method for backing up.
I've been playing around with Carbon Copy Cloner[4] more recently.
The ideal goal would be bootable backups to a disk image hosted remotely but that doesn't appear to be possible[5] - so I'm resigning myself to file-based instead - no bootable disk image, but at least I'm a little more confident in my backups? And a single "file" (or image) becoming corrupt doesn't blow away the rest of my backup ¯\_(ツ)_/¯
If anyone has any suggestions or ideas, I'm all ears.
Edit: Probably worth noting that in this case machine A was running 10.14 (and HFS) and machine B 10.15 (and APFS) - but I'd imagine 10.15 should be able to open a 10.14 HFS sparse bundle without an issue.
> It would be great if we stop adding features now... I wish there was a Postgres branch that took previous version and then just applied optimizations and bugfixes. No more.
To be fair, quoting from the article:
> There are no big new features in Postgres 13, but there are a lot of small but important incremental improvements. Let's take a look.
But also, in general, yes there are pieces of software that do this - most recently Moment.js[1]. There was some discussion earlier this week[2].
> Every submission and comment must teach everyone something, expand views, ideas and contribute to society in some way. I don't think you telling how much trash you're picking is contributing to society.
I don't know about that. Last year the OP and friends worked to pick up and document trash and now, a year later, that information has been used to make informed decisions about how to keep our streets - and society - cleaner.
I'd argue that OP has quite definitively _contributed to society_.
If he'd just posted "I picked up some trash" - I could understand your comments, but he's done the work, gathered data, written about it, etc. So w/r/t to _teaching something_, I know more now than I did before reading his post.
Quite frankly, I could attempt to compare your contributions to society (aside from the snarky, dismissive comments on HN) but you've opted to hide behind a new, anonymous account. If you believe a submission is off-topic, just flag it, creating a new throwaway account just to disparage it seems a bit extreme.
And please understand, I don't say this to disparage you or insult your incredible intellect - just in the hope that perhaps I can _expand your views_ on how OP's submission is of interest to members of this community.
> I don't think talking about how much trash you pick is any interest of us
That's rather presumptuous, it is of interest to me.
And considering the previous post from last year received 100+ upvotes and 100+ comments, I think it's safe to say that it's of interest to others as well.
Sure, but I wasn't suggesting that Webkit is an original work of art - the discussion wasn't about the history of rendering engines and browsers - it was about which companies _today_ are willing to maintain their own rendering engines and browsers instead of just skinning Chromium.
- Apple has Safari which uses Webkit (which was forked from KHTML as you noted)
- Mozilla has Firefox which uses Gecko (originally from Netscape)
- Google has Chrome which uses Blink (forked from Webkit)
- Microsoft has Edge which uses Blink
- Opera has Opera which uses Blink
... The only two major players currently maintaining a non-Chromium and Blink based browser are Firefox (mentioned by the OP) and Apple (mentioned by myself).
I was simply trying to provide some additional context about the history of Chrome, perhaps I should've also included the context about the history of Safari.
> they will slowly stop bothering and start cartelizing around Chromium, one way or another, because no corp except for Mozilla solely depends on their browser
I'd say Apple falls into that category (although they don't solely depend on their browser, it is a major part of their ecosystem) - the day they stop maintaining Safari and just ship Chrome (or a skinned Chromium) on iOS and macOS is the day I stop using the Apple ecosystem.
> He has built a $150 billion company from the ground up
That's a bit of a stretch.
The company was founded by other folks (Martin Eberhard and Marc Tarpenning) in 2003, he invested in 2004, joined the board of directors, ousted the CEO in 2007, and was then only able to refer to himself as a cofounder after settling a lawsuit.
Musk didn't build anything "from the ground up," he took control of a company that already existed and grew it into something larger - still admirable, but let's not rewrite history. Musk didn't create Tesla and he wasn't one of the original cofounders.
> If it fails it raises an Exception... If your server is down, my application would crash too
So first off, let me just say that I completely agree. If this were the case, that'd be fucking atrocious and would definitely be a blocker for using it.
But I'm curious how you came to that conclusion.
It took me < 2 minutes of looking at the source code[0] to determine that your claim was incorrect. Not only does it appear to gracefully handle the server being unavailable, the developer literally commented that code explaining that they wanted to ensure users could continue uninterrupted if the errorship server is unavailable.
> We give people the benefit of doubt.
> We only consider people to be not authorized if the backend comes back with an authoritative answer to that effect.
> Else, any errors or any other outcome; we assume authorization is there and also assume they belong to the highest pricing plan: Enterprise
> # failure of errorship should not lead to people been unable to ship exceptions
And it took even less time than that to run a new Python Docker container, install the library, run the sample code, and validate my assumptions[1] (the first attempt fails because the key is invalid, I disabled Internet access for the second attempt and it succeeded).
So I'm legitimately curious - did I miss something? Is there another failure case I didn't catch or test for? Or did you just make an assumption and not bother to verify it? And if it's the latter, why? What was the point? Like, to be frank, if this was a news piece I could understand the (possibly inaccurate) commentary. But why take the time and energy to write your comment and tear down someone's personal project with seemingly inaccurate claims?
(To be clear, no affiliation with errorship, I'm not even a DataDog user. Just a random dev browsing HN).
bat and exa also have ~19,100 and ~9,300 stars, respectively, on GitHub and (presumably) even more actual users - unless your project is that popular, I honestly wouldn't worry about it.
If your project does get that far, it'll start popping up in all of those package managers. To be super blunt, if you're interested in building and sharing CLI tools written in Rust, I'd just start building and sharing CLI tools written in Rust and stop worrying about all the different package management solutions available. crates.io is the standard for the Rust ecosystem and is more than sufficient until your project has hundreds or thousands of users - most package managers won't even accept your package until it has a decent amount of popularity (e.g. in use by more than 50 people).
Once the project is popular enough that it warrants placement in package managers, you'll know because a user will either file an issue requesting the project be added to a package manager or they'll simply do it themselves :D
TL;DR Just publish it on crates.io and call it a day.
> What I'm most familiar with when it comes to publishing CLI tools is NPM. However, since Rust requires a build step I don't really feel like crates.io is set up for that on its own.
FWIW, I'd second hazebooth's nod towards simply publishing on crates.io.
I think you may be overthinking this, but that said I personally go the route of having CI cross-compile binaries for each OS and arch type that I host in order to minimize dependencies on the systems that run them (e.g. avoid installing the Go or Rust compiler).
I don't personally maintain package manager options (e.g. apt and brew) for projects because, as you mentioned, it'd be a lot of work. Plus, to be quite frank, when and if a project is popular enough that a large enough audience uses it, one day you'll find that someone else has added a package for it to e.g. apt or brew.
But given your familiarity w/ NPM - if you are interested in precompiling binaries for each system - you might want to take a look at Cloudflare's wrangler[0], their tooling for interacting with Cloudflare Workers. wrangler is published to both crates.io and NPM (the latter using a script to pull down pre-compiled binaries they host).
Edit: Another option, if you want really want to make your project available via a "package manager" that isn't crates.io, would be to release a Docker image. This is an option for CLI tooling - e.g. Hashicorp publishes Packer[1] and Terraform[2] Docker images. That way you don't need to worry about compiling binaries for macOS, linux w/ glibc, linux w/ musl, etc. Just publish a single Docker image, ideally as small as possible.
Tariffs on goods coming into the US are paid by US residents. (Just had to pay customs to clear a shipment from the UK - I had to pay the tariffs, not the seller.)