This behavior is the same whether you use Turbopack or webpack. It doesn't make sense for us to couple ourselves with ESLint when there are many viable alternatives. No other popular frameworks run ESLint automatically during builds. This change in Next 16 brought up closer to parity with other frameworks and bundlers.
> typescript validation
There's no change here with Turbopack. We do still run `tsc` automatically to check your types. That's part of `next build` and not Turbopack. However, we may remove this in the future for similar reasons.
There's no good reason for the bundler to call the typechecker. Bundlers strip types. Historically this was done with Babel in webpack. Modern versions of Next.js use SWC for type stripping in both webpack and Turbopack.
There are tradeoffs to both approaches, and I think Vite's choice makes sense in the context of their broader minimal-bundling-in-dev design, but it makes less sense for Turbopack (as well as webpack and Rspack) where we produce bundles in dev.
Admittedly hosting Next.js can be a bit harder than a SPA if you're using all the features of the framework, but if you're scaling and you don't want to use Vercel, you've got a lot of other options, including those provided by OpenNext. We've got a nice example repository here: https://github.com/leerob/next-self-host
What's more concerning IMO is that despite the fact that I can't find a CLA, their pricing page claims that if you buy their support contract that they'll give you the software under a "Commercial" license: https://min.io/pricing
I worked on this while on the Instagram Server Framework team to leverage LibCST and solve some of Instagram's own problems. We took a lot of inspiration from other lint frameworks (notably, Flake8 and ESLint).
I left the team before most of the work to open source it happened. It looks like a lot of work went into the documentation, command line interface, and configuration system. Congrats to the whole team! I hope this can be useful to other projects outside of Facebook.
I'm with you, and I prefer "dumb" devices, but you can still buy these blu-ray players and not connect them to the internet.
The internet connectivity is sold as an additional feature so that you can use your blu-ray player to watch Netflix. I agree that I don't want logging on a device like this, but if I was going to connect one of these to the internet, I would at least want regular security updates.
Sure, there's probably less exposure from nuking the profiles directory, but I don't think you're being fair to containers:
- Containers are a feature built into Firefox, these extensions just expose a UI for it. The Multi-Account Containers plugin [1] is published by Mozilla. You don't need to trust anyone but Mozilla to use that base set of functionality.
- The container functionality in Firefox is the result of some work from the Tor Browser being upstreamed into Firefox [2]. It seems reasonable to assume that it's well-implemented.
- The limitations of the extension that you linked to don't seem any worse than your profile-segmentation approach. It's just saying that it's possible for multiple websites to get opened in the same container, which is similar to how you could end up opening multiple websites in the same profile.
See if your preferred distribution has a kernel backport available. Most have backports of the kernel because it has relatively few dependencies and is backwards compatible, making it easy to backport.
E.g. Debian currently has a 5.5 kernel in buster-backports[1]. However, Debian's backported kernel doesn't get the same level of attention and isn't subject to the same security policies as stable releases, so may be lacking some security patches that the stable kernel has.
If the data structure has a reference count of one, you can safely mutate the data structure instead. Many persistent immutable data structure libraries use this as an additional optimization.
As others have mentioned, Digital Ocean and Linode would probably be good options here.
If you're looking for something even smaller and cheaper than $5/mo, I've had luck with BuyVM. They've very cheap, have good customer support, a nice panel, and you get an entire /64.
A large amount of that 1.5 MB of code is to shim around the incompatibilities between different versions of the shared libraries that ship with Android. The root of the problem is that not everyone is on the same version of Android.
I've got an old 2013 Moto X, and I've recently started using Messenger Lite on it. You'll likely need to manually install the APK, because it's not available in the Play store for the US market, but it's definitely a lot faster.
The value of the network does go up the more people use it, and therefore, there are more transactions per user. However, the amount of transactions that each user produces will probably not scale linearly with the network size.
Granted, none of these were very high-profile, and Google hasn't acquired any other web search engines either, but to say "Google has never had to buy a competitor" is naive.
They've also spent a lot of money acquiring competing companies that aren't related to their core business. YouTube competed with Google Video before they were acquired. DoubleClick competed with AdSense (and arguably, Google stole DoubleClick's model). Waze competed (and still competes) with Google Maps.
I used to work at Amazon, and I liked their leadership principles.
They're intentionally contradictory, but that's just an acknowledgement that perfection is impossible. When you choose to focus on one aspect of your career, that's often going to be at the detriment of something else. This also means that there's always room for career development and self-improvement.
Regarding D2: If you're going to go with bcache, make sure you're using a kernel >= 4.5, since that's when a bunch of stability patches landed (https://lkml.org/lkml/2015/12/5/38). Alternatively, if you're building your own kernel, you should be able to apply those patches yourself.
Engineers are expensive. Google's research blog probably isn't a very high-traffic surface, and most visitors are probably on modern machines and fast networks. It doesn't make sense to spend a bunch of engineering resources on optimizing something like this. So instead, you do whatever is easiest to implement and maintain.
There was a change in Next 16, not Turbopack, that removed `ESLint` during `next build`: https://nextjs.org/blog/next-16#breaking-changes-and-other-u...
This behavior is the same whether you use Turbopack or webpack. It doesn't make sense for us to couple ourselves with ESLint when there are many viable alternatives. No other popular frameworks run ESLint automatically during builds. This change in Next 16 brought up closer to parity with other frameworks and bundlers.
> typescript validation
There's no change here with Turbopack. We do still run `tsc` automatically to check your types. That's part of `next build` and not Turbopack. However, we may remove this in the future for similar reasons.
There's no good reason for the bundler to call the typechecker. Bundlers strip types. Historically this was done with Babel in webpack. Modern versions of Next.js use SWC for type stripping in both webpack and Turbopack.
> aggressively cache node modules
We aggressively cache everything. We don't have special-casing for `node_modules`. See our blog post about our caching system: https://nextjs.org/blog/turbopack-incremental-computation
Interestingly vite does actually special-case and cache `node_modules`: https://vite.dev/guide/dep-pre-bundling
There are tradeoffs to both approaches, and I think Vite's choice makes sense in the context of their broader minimal-bundling-in-dev design, but it makes less sense for Turbopack (as well as webpack and Rspack) where we produce bundles in dev.