I work at a company with thousands of engineers and have people hitting $200 limits in just a few days. I think the shortest was around 1.5 work days.
2,156 karma · joined July 1, 2008
[ my public key: https://keybase.io/wbond; my proof: https://keybase.io/wbond/sigs/Pvj8uB_kGtdPqUExH2MaYD9hC0AHJhavd6gm8O0jpr8 ]
Either way, congrats on your hard work and success!
Ideally you want your scripting to handle of the weird gotchas of different versions of host OSes, etc. Granted my work is cross-platform so it is compounded.
So far I’ve found relying on extensive custom tooling has allowed me to handle transitions from local, to Travis, to AppVeyor, to CircleCI and now also GitHub Actions.
You really want your CI config to specify the host platform and possibly set some env vars. Then it should invoke a single CI wrapper script. Ideally this can also be run locally.
Meanwhile, other people spend far more time maintaining and protecting their cars that can use cheaper gas and they have full access to. But they have to be much more vigilant about what neighborhoods they park in, and once two years comes around they can no longer get replacement parts, and if the lock has an issue, people can trivially steal their car.
Or maybe this is just a tortured analogy to start with. If you don’t like Apple, just buy something else.
From what I understand, it is part way there to fully supporting what is needed on macOS/iOS, but then it is hard to throw money at it when it isn’t a replacement yet, especially since sponsorship isn’t guaranteeing work goes into your needs.
So sort of a chicken and egg situation. Recently it seems work has been focused on some mainframe architectures, and I wasn’t actually using it at all, so I stopped sponsoring.
All this to say is that it isn’t specific to mold, but open source projects in general. If the source is available and it works, there is no incentive to sponsor, and if it doesn’t yet do what you want, there isn’t a guarantee that your sponsorship will move the needle.
BadTLS explicitly exists to test certs that you generally should not, but often do, run into in the wild. As a result, most software handles these in poor ways, with error messages that are unhelpful at best.
Writing tests that utilize a custom root doesn’t seem all that much work for a library supporting TLS.
That said, I am still contributing the community, albeit a little slower. Hoping to have a first-rate Swift syntax done in the next month or two, plus continuing to plug away on some Package Control work.
Congrats on the new role and continuing to push yourself!
I’ve also done gigs for 7, 5, 2 years, one for 8 months and now I’m 2 months into my new gig. I would concur that ramp up speed has been pretty similar at most. I’m not sure the first move (after 7 years) was harder than the others.
Honestly, I think it tends to be harder emotionally to walk away from the situation. From the familiarity to the network, it can feel weird leaving that all behind, even if there are obvious reasons you need to leave. Once you’ve made the break, starting new tends to be similar: spending a few months getting familiar with the exact tech stack, the people, projects and business. Usually after a handful of months you’ll start feeling in the groove and know enough of the environment to feel like you are making serious contributions.
30 incremental builds an hour sounds pretty high to me, unless you’ve got a smaller app. On Intel machines, I’ve been seeing minimal incremental build times of over a minute. The M1 obviously make some pretty significant improvements in this situation.
However, while I’m relatively new to the iOS world, it seems linker performance is a fairly hot topic. I know more than a few people are eyeing support for Mach-O linking in mold, based on the massive speedups shown for Linux.
I’ve had one for the past year with zero issues also.
I don’t need the port to be removed, but I doubt I would regularly use USB-C. It is more difficult to plug in than lightning, and will still suffer from the same cable issues.
I care more about making it easy for people to pay me than getting “free” certificates that cost me hundreds of dollars in labor costs.
Everyone talks about LE like it is perfect. I’ve just determined after using it at four different orgs that for smaller shops it tends to take more time/money to get it working than using long expiring certs deployed via an automation system.
Honestly, setting up even more automation, like you suggest Apple provide, would probably cost 5x in labor as being able to purchase 3 year certs for the next 12 years.
Automation is great when you have scale. In this case, I don’t. I tend to work at smaller companies, so I’ve never worked at an org big enough for the automation to pay off versus buying certs.
This means every three months you need to re-authenticate with Apple Pay. But there is no Acme client for authenticating with Apple Pay. So instead, I was having to re-authenticate something manually every 3 months. It involved logging into an Apple Developer account, downloading a PEM file, uploading to my server and then clicking a button in the Developer Account to check the file.
After doing that dance, I happily paid for 2 year certificates from RapidSSL. Now you can only buy one year certificates. I really hope the CAB isn’t successful in making those non-conforming and requiring shorter certs.
There are plenty of other environments where certificate automation is not possible. And honestly, I haven’t seen arguments as to how on-machine automation is more secure than requiring someone be involved in the process.
While I’m dreaming about improvements to the CA ecosystem, having some way to actually prove your are the company you claim would be amazing. Instead we are actively removing support for anything that tried to provide that…
CI is a script, and the YAML configs for those various services configure the machine type, OS and toolchain. Everything else is contained within the script. Sometimes even toolchain setup is handled by the script.
Not following this model has wasted so much time when migrating services or trying to tweak what CI does.
With a script you can run it locally to ensure it performs the steps desired, leaving the CI “setup” to minimal environment/toolchain debugging.
Instead of having to manage groups and the files within them, tab selections are very fluid and low overhead. From the user experience perspective, I think they are as fundamental as multiple selections and Goto Anything are.
There are some docs at https://www.sublimetext.com/docs/tab_multi-select.html. However, I recommend opening a folder and holding down ctrl/cmd when selecting files from the side bar, Goto File, tab bar, Definitions popup, etc.
It integrates well with ctrl+tab, and the Definitions navigation flow is pretty user-friendly.
This will be happening “soon”.
This allows us to have a better feedback loop and tighter communication.
We weren’t originally able to include it because we had to backport Mac arm64 support to Python 3.3, since we include that for compatibility with ST3 packages.
Edit: I should note that my original tweet thread has a few more details https://twitter.com/wbond/status/1379401771911643136
Clearly you disagree with that decision, but we do communicate with our users pretty much every day. We simply decided trying to communicate and gather feedback from tens of thousands of users was less productive for a team of six than hundreds of engaged power users.
We’ve just been releasing those discreetly during this current dev cycle since we’ve got a huge user base and wanted a smaller group to test some of our bigger changes on.
For our future dev cycles, our dev builds will be returning to our site.
We are doing a big release because our current licensing scheme requires a "major version" release for paid updates. If we did a release once a month, they would all be trivial features, and wouldn't justify a major version bump.
For license holders, we've actually been shipping new dev builds every one to two weeks. However, since this is a major release, it has some very significant changes that need testing, refining and polishing. I don't think anyone in their right mind would ship a half-finished product and call it a major release, so we've been doing the work that shows it is a major release. The downside of bigger releases is that sometimes they end up dragging on a little longer than you want, and we'd rather uphold our vision for the product than have a release done a few months earlier.
As I mentioned in my post above, we've got some changes coming that will help address the "major version" issue and allow us to take on a faster release cycle. That said, I'm not sure I agree that new releases once a month are a good fit for the majority of users. We do, however, provide dev builds for users who do like seeing changes quickly.
We've got a super active group of some of the more prolific plugin developers that we interact with on a daily basis on our public Discord server. They definitely provide a lot of feedback and we make a point of listening to what the have to say.
The reality of it is that most open source developers wax and wane in their development work. The ones who stick with projects for years and years tend to either do open source work related to their day job, or are at least partially employed to work on the open source work. Others will get an itch, scratch it, share it, improve it and then be satisfied.
There haven’t been any significant gaps in our release cadence since before I joined the company in 2016.
That said, the current dev cycle has been a little longer because people do expect more from major version releases. We’ve got a large collection of new features, improvements and bug fixes coming with this release.
We’ve addressed over 600 issues on GitHub in the current release, added some pretty significant changes, and laid the foundation for more to come. IMO, it is by far the most significant release we’ve ever done.
We’ve also got some changes planned to help shorten our release cycles moving forward!
The open source model makes sense since it will need to have tweaks and fixes to support various language servers. That combined with a very small development team (six engineers across our two products), would probably lead to slower development, and it would be tied to the release cadence of the main product.