I pin the responsibility on Apple. They created a bounty system which incentivized people to build their livelihoods around finding these issues. They subsequently decided they wouldn't pay out those incentives essentially at random. If putting food on the table means getting paid for vulnerabilities, it's only rational to sell your work to whoever else is going to pay for it. Apple _created this market_ (and, you might argue, put the vulnerability into production). The only bad look here is Apple, imo.
No, this is simply cause and effect. I wager a number of security researchers don’t find any moral issue with selling exploits, but prefer to be paid a bounty by the big corp due to ease and cachet. If that’s no longer tenable, they will hold up their middle fingers and just keep doing what they do. You can tell them they’re acting immorally all day long, but you will only be wasting your breath.
We live in a capitalist society that the companies at the very top absolutely love to exploit. They also love to exploit "but think of the <patients>,<the people>,<the children>" and so on.
By this logic, you're not even pretending you're better than this. You're not angry at Apple because they love to exploit, you're angry at them because you're not powerful enough to exploit others too.
Do you agree with this statement? If not, I think there's a contradiction. You are morally obliged to do the right thing even if there are entities who don't.
I am a current Fly customer (personal and work), and have been happy with the service. Will likely be trying this out. That said, the marketing tone of this final part of the blog:
> More to come! We’re itching to see just how many different ways this bet might pay off. Or: we’ll perish in flames! Either way, it’ll be fun to watch.
Why? If you're using something like Fly you should 100% always have a fallback plan ready. You are gambling using smaller players to get cheaper services or some other benefit the big players don't offer in exchange for the very real possibility of a random day they announce 30 days til they permanently shutdown with zero migration path.
I don't think it's in poor taste to acknowledge exactly what everyone should understand and be prepared for.
You can communicate those ideas specifically without hiding it beneath the veneer of relatability. The entire post started with this bit:
> But, come on: you never took us too seriously about K8s, right? K8s is hard for us to use, but that doesn’t mean it’s not a great fit for what you’re building. We’ve been clear about that all along, right? Sure we have!
which already starts the post in a bad space for the reader. I have cognitive whiplash from what is intended. "We DON'T like Kubernets UNTIL WE DO but then WE MIGHT NOT IN THE FUTURE". Clear meaning is far more appreciated.
We're not trying to sell you so much as we are trying to put you in the headspace we are in building this stuff. Your summary (we DON'T until we DO but MAYBE NOT) does feel pretty true to life!
Interesting! We're mostly not kidding about that. We launched in 2020 with a scheduler that looks a lot like how K8s works†. We ran into scaling issues. Instead of scaling a globally coordinated "eye in the sky" scheduler, like Nomad and K8s offers, we relaxed a constraint ("when you ask to run a job, we'll move heaven and earth to put it somewhere") and wound up with a totally different scheduling model (a market-based system that bids on resources, where requests to place jobs are all effectively fill-or-kill limit orders).
This was a bet. We're bullish about this bet! Even without K8s, having core scheduling be "less reliable" but with a simpler, more responsive interface puts us in a position to do some of the "move heaven and earth" work that K8s and Nomad do in simpler components (like: we can write Elixir code to drive the scheduler).
But it might not pay off! That's what makes it a bet.
† (see: comments on this thread asking why overengineered and wrote out own version of stuff; the expectation that you'd run a platform like Fly.io on standard K8s or Nomad is pretty strong!).
I made the same bet with cloudways which is now owned by digitalocean. they filled a gap for me, and I was ok if they decided to close shop; I am glad it didn't go that direction, and they are part of a bigger company that also was once a small company, but they are now publicly traded. you make your bets...
Yeah, agreed. I use Eleven Labs a lot but this was a very compelling demo to consider changing. Also, curious that you mention Bark - I never found Bark to be very good compared to Eleven Labs. The closest competitor I found was Coqui ( imo ), but even then, the inflection and realism of EL just made it not worth considering other providers. ( For my use case, etc. etc. )
Could it just be that investing in Apple could be seen as "I get all the upside of any benefits I would get in investing in TSMC, with the additional upside of getting exposure to all of Apple's product decisions in non-chip related markets ( eg financial, content, et al )?" Like, if TSMC invented a new fab process tomorrow that was amazing, that'd be cool, but it'd be unlikely to make a substantial increase in stock prices in its future as that sort of is how TSMC normally behaves. That's their whole business. But Apple has a history of unlocking new markets and adding new cash flows, plus doing a pretty good job maintaining their current cash flows, so you get more upside on Apple, plus a hedged exposure to TSMC?
I say all that with full acknowledgement I'm just like, playing a guessing game at professionals here.
Currently using Swift for a side project. It's "server side" in that I have a server implementation that runs on an iOS device and in Linux on a server. Using SwiftNIO for the server pieces, as it's from the Netty folks, and I really like their design.
I've been happy with it thus far, even though I should note that my usage is pretty low stakes / trivial. It has just enough of what I want of modern language conveniences that I'm not sad about using it. I certainly derive some happiness from having a zero impedance inclusion on the iOS and server side; conversely, were I to use Rust, my early reading seemed to indicate I' have to navigate a bit of FFI and library inclusion on the iOS side that I'd much prefer not to.
So, at hobbyist level, it's been fine. If I were to go purely on technical merits and language niceties I would have chosen Rust, as the depth of language features and standard library features is really really nice for me, but the fact that I can just have something that works in either of my desired platforms has made it okay to deal with a slightly less mature (IMO) ecosystem.
Also, as a note, I've done just a tiny bit of SwiftWASM with this same toolset, and it's not bad either. Pretty far behind Rust's WASM capabilities in my experience, but accomplishes what I need and is generally nice. Tokamak ( a WASM-friendly UI framework like SwiftUI ) has been nice in my initial usage as well. I'm definitely at a firm hobbyist level of using this stuff tho, no production anecdotes to give you unfortunately.
If you're near the Canadian border, I've heard some anecdotes about folks crossing to get cheaper insulin. I've not done it, though was on the fence about doing it.
Also, I know that some makers ( Eli Lilly in particular ) also offer need-based aid programs to provide insulin. If you reach out to them and they're manufacturing, I believe you can get the insulin at near free if not free. ( This is also true for many medications that fall into the commonly-used category, you can explore manufacturer sites to see if they provide aid for a particular drug that is in your list )
Corollary to this: if you have insurance, it's also worth asking your insurance provider if they know of any aid programs that can assist. I was shocked to discover Humana has a team that will help you discover aid programs to cover the rest of the cost that Humana might not cover.
Obvs it would be great if they covered 100%, but if you're trying to cover your ass right now, it's worth asking your provider about.
And as another note, if you qualify for aid programs, and they are not oversubscribed, then you should sign up even if you can afford not to - if you feel bad, donate the difference to an appropriate charity or cause.
Because the number of people using aid programs is a major factor in getting them identified and improved.
I'm a Michigander and while I've never brought insulin, I've brought unapproved painkillers across the border regularly. My uncle (T1 diabetic) has brought insulin.
I say this as someone who bought some INTC a while back expecting something like the following to play out.
Last year's (and somewhat, continuing) chip shortage will combine with a view in the US that chip-availability is a national security issue. At some point, the US will make a strong case for in-nation chip fabrication as a national push, whether that be favorable business conditions for companies like Intel, or negative business conditions for foreign chip providers. Intel already sees this, and is playing to that future game; maybe not necessarily win Apple back ( as they say ), but to play to a future environment where many companies that aren't 3T mega corps to not have very many attractive domestic options other than Intel.
Certainly I'm just playing a guessing game here, but that may be a potential future market they pitch to someone. "Apple will continue to play their own game, but here's a whole other market we see in the future".
In order to regain Apple as a customer, Intel would actually need to commit to becoming a foundry. The catch is that Intel has tried to become a foundry several times before and failed, and there's no reason to believe this time will be any different. Intel survives off of fat cat margins on silicon by selling premium systems (especially in the server market), and the foundry business model is simply unable to provide those kinds of margins. What would impress me is if Intel starts poaching the key people from foundries that are needed to sell and support the business model internally.
I enjoyed this article, but I’m confused. The section raising the question about how this has affected other asset prices seems to just posit the question without establishing how the banks actions would have done so. Is there some obvious link between the FED buying mortgage backed securities and technology stocks going up? Or should it be inferred that by buying those securities they just put more money into the system that is creating the situation they describe? Thanks for any explanation.
Just a note to anyone looking to go down this road: IO performance is still pretty awful last I checked. If your workflow is IO intensive (non trivial Rails app, let's say), proceed w/ caution.
(Addendum) I did a Fast Ring update on a separate machine and did not see substantial performance improvements, but the comparison is not valid between the machine linked and the machine I tested on, so I'd be hesitant to say that the performance hasn't improved at all, just that IO performance is definitely a weak point to WSL.
We have some improvements coming in Creator's Update and more substantial improvements planned in future releases, once we've completed some work with the NT kernel filesystem team.
Is this why Visual Studio is scp'ing source files around, instead of just copying the files to that /mnt/d directory and invoking the compiler there? That seemed like a big hack to me and it wasn't exactly clear why they were doing it that way (near the end, last five minutes).
Wow, that is pretty fast. I played w/ doing CSV parsing taking advantage of SIMD string lookahead a while back ( https://gist.github.com/netshade/aa9e836e843c8e84b97a ) and found it to be quite fast as well, as I had assumed (perhaps wrongly) that the cost of navigating back and forth between the CPU and the GPU would erase any performance gains. I suspect ( it's been a while! ) that the SIMD approach would be faster than GPU, but tbh after working on it for a bit, then comparing it w/ mawk's (http://invisible-island.net/mawk/mawk.html) performance, mawk still beat my approach handily, and did it w/ way more functionality. Which is all to say that mawk is pretty amazing and worth checking out if you're in the market for parsing CSV fast.
