I use `ess` (env sample sync) to sync my `.env` with `env.sample`: https://github.com/acaloiaro/ess.
This of course does not share the secrets themselves, but helps document what secrets an application requires.
1,540 karma · joined December 12, 2014
This of course does not share the secrets themselves, but helps document what secrets an application requires.
Allthough to the grandparent's point, whne you're dealing with executables or libraries outside of your control, the only true way I know of to get a "handle" on them is to create a process, with its pid becoming your handle.
In situations like image processing, conversion, video transcoding, document conversion, etc. you're often dealing with non-Go-native libraries (although this problem transcends language), and there's no way to time-bound processes. That is to say that you often need to consider the Halting Problem and putting time bounds and preemption around execution. So what I've had good success with is adding a process manager around those external processes, and when a timeout or deadline is missed, kill the pid. You can also give users controls to kill processes.
Obviously there are considerations with resource cleanup and all sorts of negative consequences to this, depending on your use case, but it does provide options for time bounding and preempting things that are otherwise non-preemptable.
I'd forgotten how emblematic "pre"-prefixed meetings are of larger organizations that have meetings to plan for other meetings, e.g. "Pre-planning", "Pre-OKR brainstorm".
Seeing pre-meetings always reminds me of a scene in Office Space where "The Bobs" are seen [1.] in front of a whiteboard that clearly reads "Planning to Plan". It's a subtle visual of the movie's central theme of poking fun at corporate culture.
It's been a real treat being in an environment where we don't plan to plan, or have such a vague concept of our meetings that they're best described as a "syncs".
Is there something in particular that's flawed with Odoo's business?
Why build higher order concept Y when it's simply built on primitive X?
Why build the C programming language when C compilers simply generate assembly or machine code?
---
A sensible answer is that new abstractions make lower level primitives easier to manage.
I believe you're referring to the ACA's "individual mandate", which imposed a federal tax penalty for being uninsured. I won't argue whether that makes it illegal or not, but I can say that the individual madate was eliminated by the Tax Cuts and Jobs Act in 2019 [1]. There's no longer a federal tax penality for being uninsured.
[1] https://www.census.gov/library/visualizations/interactive/pe...
If your question was actually serious, this is a non-exhaustive list.
I understand where you're coming from; I believe the premise is that because Kickstarter receive their fee whether projects deliver or not, that it's profitable to not remove any projects. That's of course true in the short term.
But the cumulative effect of that myopia is that the projects seeking funding on the platform has plateaued for years. The resulting lack of trust in the system has culminated in fewer projects using Kickstarter, because fewer users trust Kickstarter to adequately police projects. Robust project policing would lead to greater trust, a greater number of projects reaching funding goals, and ultimately more fees for the company. It's emphatically in their interest to remove unsavory projects, regardless of the immediate fee loss. The increase in trust is a multiplier that'll far exceed any immediate loss.
Long live Postgres queues.
But I strongly agree.
This part is the most exciting to me. Given the rest of the release announcement, I'm assuming this means that it'll be built in Rust rather than embed Node. While I'm not a Rust zealot of anything, I'm very partial to not embedding Node. Particularly when it depends on using Vercel's now-abandoned pkg[1] tool.
This line really excited my PR-spin senses. The set of people working on automobile R&D who are good candidates to work on "generative AI projects" is so small that it's hardly worth mentioning. "Many employees" will be moving to jobs within Apple only insomuch as ~5% of 2000 people is arguably "many" (or whatever the size of the autonomous vehicle software team is).
I understand this line as a large layoff announcement that reads more like an internal team reassignment.
For years I've used my own terminal UI player (di-tui) for di.fm. At some point in the not-so-recent past, di.fm added Cloudflare's WAF, which prevents me from using one of my app's features: managing channel favorites within the app.
To be clear, I'm a paying di.fm customer, and my app only works for paying customers. But now my preferred method of listening to di.fm is slightly hamstrung because Cloudflare's WAF sits between me and little string token available to every browser that accesses di.fm (even non-paying customers).
This line reminded me that we all need to beware of the "anti-pattern" police. Some develpers use this term effectively by explaining precisely why something is an "anti-pattern".
But more often it's used as a way to shut down conversation and any actual critical thinking. There's a lot of nuance behind what makes something an "anti-pattern", and simply declaring something an anti-pattern isn't enough. "This is an anti-pattern and this is why ..." is enough. But I still avoid using the term regardless.
FYI I'm not saying the author is the anti-pattern police, but it does sound like they've found themselves on the police's radar.
Google, please use less grug brained explanation of baseband processors [2]. ty
This post is about securing the firmware that runs on these little processors. When baseband firmware is compromised, it can lead to complete device compromise.
I don't dispute these facts. And I don't think they dispute my comment. By mentioning US v. Microsoft, I pointed out that there are similarities between Microsoft in the 90s and Apple today.
> b) Global and domestic iMessage usage is relevant. In fact it is the whole point. You need to demonstrate that there is an absence or distortion of a market for anti-trust laws to be applied.
Thank you for the correction.
> c) Apple is not trying to eliminate Beeper, they have no monopoly in anything and there is clear evidence of a fair and functioning market by the presence of WhatsApp, Messenger, Telegram, Signal etc.
Unless one can believe that Apple is both willing to block Beeper and not eliminate it, then Apple is trying to eliminate Beeper as a Messenger competitor. From their statement: "We took steps to protect our users by blocking techniques that exploit fake credentials in order to gain access to iMessage."
I think Apple has a reasonable argument for doing so. Though, in a world where Apple controls the only App Store where iOS users are blocked from downloading alternative SMS applications, they do hold a monopoly over both how iOS users install applications, and the only SMS application available on iOS: Messenger. Non-iOS users who want to message iOS users with the same quality of service as iMessages may only do so by installing 3rd party software. Otherwise they need to implicitly agree to having messages treated as second class, to Apple's likely enrichment. I think reasonable people can perceive some amount of anti-competitive intent in Apple's action. Should Apple be able to block 3rd parties from using the iMessage service infrastructure? Possibly, but it's hard to argue that doing so is pro-competition.
I think most of the concern over Apple's refusal to admit 3rd party iMessage clients will be eliminated if and when they make good on their promise to support RCS next year.
But I do believe there's reason to consider Apple's policy relative to iMessage clients monopolistic. Apple's behavior is not significantly different from Microsoft's, which instigated US v. Microsoft [1]. That case largely took issue with Microsoft's mandatory bundling of IE with Windows and the extent to which Microsoft created an inorganic monopoly. In addition to how Microsoft's monopoly came to be one, the judge also took issue with Microsoft's methodology in quashing threats to that monopoly. One could claim that Apple is taking similar quashing action relative to Beeper now.
Microsoft of course appealed the judgement, and prevailed. But they prevailed only because the judge had broken his code of conduct in discussing the case with media; not because Microsoft's behavior was not monopolistic.
I don't believe global or domestic iMessenger usage is relevant.
[1] https://en.wikipedia.org/wiki/United_States_v._Microsoft_Cor....