wbond

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.

Totally random, but did you use Flourishlib (PHP) at some point ~15 years ago? Your name sounded familiar from a long-ago open source project.

Either way, congrats on your hard work and success!

I have a few open source projects that have lasted for 10+ years, and I can’t agree more with approach #2.

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.

Yet most people end up liking that car and the balance of features, looks and price. Sure, they’d love to not pay for premium gas and have the extra trunk space, but in the end they’d much rather have a car that basically never gets stolen, gets updates for years, and does what they want 97% of the time.

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.

ChannelLock makes good ones with tight tolerances, smooth adjustment and accurate measurements in metric and standard (one on each side). I often use them as a first attempt and if I need more torque I check the size they are set to when grabbing the correct combo wrench or socket.

I know various companies have been looking into sponsoring his work for iOS, since it can make a big difference in the edit/build/run cycle since linking times can be fairly high. I was even personally supporting it for those reasons for a number of months.

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.

Your statement is correct.

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.

If you are looking for some other bad TLS configs, I run a site that augments this at https://badtls.io/.

Could provide a link with some info? I tried to look around to confirm but didn’t find anything. This sounds like it could be really useful.

Nah, ST is going well. Jon is the mastermind behind it all, and Ben has been doing excellent work, and Tim is rounds out the ST team. On the Merge side, Dylan and David are hard at work. I think Sublime HQ is hiring in the Sydney area also.

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!

Off topic, but nice to see you around here after years since we’ve met in person! Also nice to see other engineers from NH represented.

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.

How big is the app you are working on? How long does an incremental build take including linking and signing?

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.

My understanding is the newer 5k by LG is far less troublesome - as shared with me who’s had three different units over the past 5(?) years.

I’ve had one for the past year with zero issues also.

If you deal with a small local bank, you may be able to get a portfolio mortgage that they hold, with some unique benefits. I recently did this, they matched the rate my existing lender (big international bank) gave me, plus they offer a float down on the rate once per 12 months for a fixed fee of $975. No refinance necessary.

We recently moved to wireless charging to reduce the number of cables that break and have to be replaced.

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 see LE as generally trading low cost certs for expensive labor. It’s great when you have scale and need hundreds of certs.

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.

It also means you have to automate things that are tied to your certificate lifetime. Apple Pay on the web requires you authenticate your server, and it uses your certificate serial num as proof you still own the server.

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…

Having dealt with a fair bit of CI on a decent number of services (AppVeyor, Travis, CircleCI and GitHub Actions), I’ve come to the exact same conclusion.

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.

One of the features I am most excited about it tab multi-select. The simplicity of using it versus traditional pane management is really key, in my opinion.

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.

I am constantly wondering why the fourth controller doesn't seem to pair. Thank you!

We purposefully didn’t create a web page for it because we wanted people to engage on our Discord server. Once we are ready for wide-spread usage, we’ll release a stable build.

This will be happening “soon”.

We kindly ask that users who are interested in being part of the ST4 beta join the Discord server, and that download links not be shared outside of that community.

This allows us to have a better feedback loop and tighter communication.

Just to clarify, it is build 4100 that adds native Apple Silicon support.

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

We actually went from a singer/songwriter to a duo and then a full six-piece band between 2016 to 2019! We've been putting out albums and EPs quite a bit, just been quiet in the public sphere since late 2019 since we've been working on a double-album. ;-)

Find in Files has had a number of improvements in ST4, including defaulting to ignoring files in .gitignore, defaulting to ignoring files excluded from the project when right-clicking a folder, along with some other tweaks and fixes.

We intentionally decided to have the dev builds for ST4 go to a smaller group of people, paired with a low-friction communication medium.

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.

The “active” version of Sublime Text are our development builds.

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.

Part of our development pace is that we are a small team (six engineers), bootstrapped, maintaining multiple products, and looking to do things in a way that fits with our vision for the products. We want to build products that are around for the long haul – Sublime Text has been around for 15 years. We'd rather focus on quality and performance than adding lots of features.

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.

Just to clarify, we’ve done major releases in 2016, 2017, 2018, 2019, and now early 2021. We also released a second product (Sublime Merge) in 2018 and did a major release of that in 2020.

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!

We looked into the protocol, but unfortunately it made a number of poor architectural choices that leads to many language servers not implementing the protocol properly. This effectively requires custom integrations for most language servers. That wouldn't make sense to do in the core of the editor, since we'll never be primary users on the vast majority of servers.

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.