dikei

It's from WSO2, a company selling enterprise middleware. Of course, the paper would read like something you bring to a sales meeting, not a tech talk.

I think any language with a large runtime would be out of the question, because Openwrt has to fit into system with very limited storage.

Ah, yes, you can ignore the loader + initrd. I'm multi-boot so the loader has 2 seconds timeout, and initrd is waiting for me to input my LUKS password.

Kernel boot is plenty fast with real hardware, usually under 1 seconds.

It's everything else that's slow. For example, this is my machine

Startup finished in 14.552s (firmware) + 2.885s (loader) + 741ms (kernel) + 23.116s (initrd) + 11.191s (userspace) = 52.488s

There are actually 2 equivalent problems, (voting) consensus and total order broadcast and solving one directly leading to solve the other.

It's quite difficult to do (voting) consensus like traditional Paxos correctly and quickly in the face of failures. Therefore, most systems (Raft, Zab, Multi-Paxos) aim to do total order broadcast instead, using a leader to sequence all operations and only fall back to (voting) consensus when total order broadcast is not feasible, like during leader election.

KVM is amazing.

Beside Firecracker, there're all sorts of micro-VM being developed right now, such as crosvm, cloud-hypervisor, Kata's Dragonball, all on top of KVM.

> They're a dying breed. We're forgetting how to look under the hood and understand "why something works".

Well, layering abstraction is the most effective way to deal with complexity. Our brain is too limited to know everything.

The people, who understand "under the hood", probably won't know much about what's "above the hood", like writing a website or mobile app. Therefore, we need experts on every layers.

I find it funny that he said he didn't know what to pick between 5 types of IDictionary in C#.

* Hashtable

* SortedList

* SortedList<TKey, TValue>

* Dictionary<TKey, TValue>

* ConcurrentDictionary<TKey, TValue>

I don't even know C# (just Java), yet I know that you'd probably want to use Dictionary<TKey, TValue> most of the time.

Those `Default/Service Worker/CacheStorage/` directory are inherited from Chromium, it's the same for every Chromium code base.

> it can also be quite clean when you use a sane DOM structure, CSS variables, and well thought out CSS selectors.

This fall apart pretty quickly as soon as more developers join the project. Keeping consistency between multiple team members is hard without a reference point, which is what a framework like Tailwind provides.

>> Instead, Linux is being worked on by exporting the (git) patches and sharing them on a mailing list

Once configured, you can send a series of patches to the mailing list with a single git command, and with just another command apply a series of patches from the mailing list. It's actually quite efficient.

Yeah, github Web UI tend to generate low quality commit message that's not up to the standard set by the kernel developers: no oneline short log, long lines, no signed-off line, etc. Linus simply refuses to let those kind of commits into the Kernel.

https://github.com/torvalds/linux/pull/17#issuecomment-56546...

>> It's still engineers doing X work. There really aren't that many opportunities for economies of scale with enterprise SaaS when you have SLAs and data sovereignty unless you're cutting corners.

Not really, SaaS built specialized automaton to reduce the engineering effort so that they can scale better. Therefore, if the users need to spend 1 hour/day on their infra, the SaaS can spend the same amount time to manage infra for 100s customer.

In some extreme cases, the software run by the SaaS is completely different to what the regular users use. For example, Confluence Cloud Kafka service does NOT actually run Kafka underneath, but a proprietary system called Kora that speak Kafka protocol.

Got it, so for now using `synchronized` actually prevents the concurrency benefits of virtual thread because it pins the carrier thread. Plus, there's also the possibility of deadlock when mixing `synchronized` and `j.c.u.Lock`.

`synchronized` is a lock without any ordering/fairness guarantee. Therefore, with the increased concurrency caused by Virtual Threads, there's higher chances for starvation.

`ReentrantLock` pretty much replaces every use case of `synchronize` and also supports `fairness`. The only downside of `ReentrantLock` is making the code more verbose, and inexperienced programmers might forget to release the lock.

So I subscribe to the belief that a Java multi-thread application should have at least 2 pools: 1 bounded pool for CPU-heavy tasks and 1 unbounded pool for IO tasks. I'll probably change the IO-pool to using virtual threads now, while keeping the CPU-pool on real thread.

Also, DB-API 2.0 is a standard that's followed by most database drivers, similar to what JDBC is for Java, though not as strictly enforced.

I've tried to create a tech blog for a long time. But because I'm quite OCD about my writing, it took ages to create a post.

In the end, writing became such a chore that I stopped altogether.

Similarly, for my Linux devices I use `borg` to backup to a local NAS, and use `kopia` to have another backup to Google Cloud Storage, as B2 too slow where I live.

I used to have back up on local external drives too, but stopped doing that, since the process was manual and I often forgot about it.

Yeah, I wouldn't trust their process at all, if they'd rather have the server down for 1 week instead of aborting and performing a rollback to the last known good state.

Well, being a portable platform is hard.

Even for native platform like C/C++ or Rust, SIMD intrinsic took a while to develop, and required multiple iterations to mature for each supported platform. Plus, with newer CPU instructions being introduced, the job is never fully done.

I think it'll be much faster this time around.

We took way less time to move from Java 11 to 17 compare to the 8 -> 11 migration due to the change in deployment methods: instead of deploying jar file and run it with the server-provided JRE, we now use docker to ship our app + JRE to server.

He's talking about compilation speed, not execution speed.

You still need VM to run Linux ELF on macOS, but you don't need to use full-blown emulation like QEMU if the Linux ELF is for AARCH64, unlike when you try to run x86 ELF. It's much faster this way.

To be fair, a lot of people use ZK wrong, then complaint about it.

For example, if you use it like a general purpose KV store like Redis, you'll have a bad time.

Another often encountered mistake is people, thinking it doesn't need to store much data, deploy ZK to a server with slow disk/network. Big mistake, as every write to ZK need to be broadcasted and synced to disk, a bottle-neck in disk and network IOPS will kill your ensembles.

I'm sorry, but what's hard to say about "all floating point arithmetic operations can contain errors". It's such a simple statement, that every developers learn in CS 101, that you don't even need to understand the reason to remember.

For a Postgres extension, there's a strangely lack of documentation on how to add Hydra to an existing PG installation.

That's not how I read it. I think the arrow-rs team wants a merger, and the arrow2/polars team does not oppose as long as they can keep using the arrow2 API. The responsibility to port the changes over would lie with the arrow-rs team, however, as the arrow2/polars team won't spend any effort on it.

Using hash doesn't protect you from supply chain attack either. If the publisher is compromise, any updates could potentially be malicious. The alternative is to never update at all, which can be even worse.

The main purpose of using AGPL as the original license is to force companies that have a blanket-ban on AGPL to buy a commercial license or just buy the entire project, as told by the author.

https://gist.github.com/lleyton/9c0b75d065f37333ea9851b6cad1...

It did not workout, so they're switching to MIT.