First incident posted: https://www.githubstatus.com/incidents/2nd6fyb4drjx
1,393 karma · joined August 29, 2012
In particular with regards to US law, salaried computer employees (and highly-compensated employees) are 'exempt' from the minimum wage and overtime rules of the Fair Labor Standards Act, so while it's true that you need to pay someone for doing work on an on-call shift, I don't think a US employer is necessarily legally required to pay them any _extra_ if they're an exempt employee.
Two key factors are "(1) the degree to which the employee is free to engage in personal activities; and (2) the agreements between the parties." Beyond these general factors, no universal rule applies since the details matter (frequency of calls, response-time requirements and geographical limitations, etc) in the degree to which they limit personal activities, as do any agreements laid out in a contract or company policy (e.g., how specific 'on-call' requirements and compensation are defined and agreed upon in advance).
Note that these factors have only to do with the time spent _waiting_ for a call; time spent _actually working_ while responding to a call is more clearly work that should be compensated.
The article addresses this directly and is clear that Carbon is not designed to 'compete with Rust', and instead targets a much narrower use-case:
> Carbon is for those developers who already have large codebases in C++, which are difficult to convert into Rust.
I don't have a large C++ codebase to maintain so I don't currently have any use for Carbon, but I could see it being interesting for those who do.
> I’m going to dissent here on this thread because I’m not seeing any references.
OK, here's one such reference in "The Best Baby Formula" [1]:
> We didn’t do any testing for this guide, because babies have minds of their own, and it would be impossible to control for all of the variables that might make a baby prefer one formula over another.
Now there might be various reasons why actually testing the product is difficult or unnecessary to produce a helpful, well-researched review article, but there are definitely examples of this.
[1] https://www.nytimes.com/wirecutter/reviews/best-baby-formula...
OSI in fact tried to file for a trademark on 'Open Source' in 1999 [1], but failed because the term is 'too descriptive'.
[1] https://opensource.org/pressreleases/certified-open-source.p...
1. write a 'Hello World' HTTP server to show how Tokio's async-Rust primitives work for epoll-based I/O;
2. show how the tracing crate ecosystem works to inspect and debug async-runtime tasks;
3. play with converting traces to OpenTelemetry, tokio-console, etc. for different views of the collected data;
4. play with hyper and axum to build a simple HTTP service that makes an upstream HTTP request to the YouTube API;
5. cache results by ID so it can shared across all request-handlers;
6. add 'request coalescing' to prevent multiple concurrent requests from making upstream requests in parallel;
7. fix a bug in the request-coalescing implementation that caused coalesced requests to hang when the in-flight request raised an error.
One word of caution about using any request-coalescing pattern like this on a highly-loaded server: in the case where every request fails to populate the cache (e.g., timeout / not found), you end up in a situation where all requests end up _serialized_ and can quickly lock up a server under constant load. You need to either add a circuit-breaker, or otherwise ensure that _something_ always gets cached in any otherwise-uncacheable edge case (e.g., hit-for-pass in Varnish [1].)
[1] https://info.varnish-software.com/blog/hit-for-pass-varnish-...
I found Bats straightforward and simple to use, never felt the need to reinvent the wheel there.
The cynic in me suspects that even this might be challenged. Is there anything specifically preventing trademark protections from applying to unauthorized verbatim reproduction, and only derived works?
At first, you said that if any CC could achieve net-zero emissions, then it would be significantly more cost-effective than rebuilding infrastructure. Baseless assertion without any specific numbers to cite.
Now, you're saying that if any CC could be net-zero and more cost-effective, then it should be welcomed. Well, yes, obviously.
> The number of people struck and killed by drivers nationwide while walking increased by an astonishing 45 percent over the last decade (2010-2019).
Three reasons unvaccinated-by-choice individuals continue to pose a public health burden:
1. Vaccines not yet available for children under 12
2. Economic costs of covid treatment for unvaccinated (including long covid) passed on to taxpayers / insurance groups
3. Increased risks of even more deadly / infectious / vaccine-resistant virus mutations emerging from ongoing spread
First, my lack of confidence in depending on Jemalloc 3 in production is not only the 'unknown reasons' underlying such a frozen dependency, but also due to the fact that this particular dependency is over six years old and unmaintained. Not only does this lack more recent security/bug fixes and features, but also makes it more complex to integrate with up-to-date Linux distributions (e.g., your need to maintain custom compilation patches instead of simply depending on the OS's jemalloc package).
> What I mean is that it's not known in what way the algorithms and data structures are different. [...] The differences between Jemalloc 3 and 5 are not explicitly documented anywhere, and to find out requires research.
As I mentioned, the jemalloc developer already highlighted the exact differences back in 2018, and he even provided a MALLOC_CONF environment variable to use that makes memory usage in jemalloc 5 behave like jemalloc 3:
> You could verify this by setting dirty decay and muzzy decay to 0 in the MALLOC_CONF environment variable (i.e. MALLOC_CONF="dirty_decay_ms:0,muzzy_decay_ms:0", unless I've typoed something).
There is also a very readable page on performance tuning in the jemalloc 5 documentation [1].
In your research, have you ever tried running jemalloc 5 with this configuration? I did this back in 2018, tested/verified against my production workload, and have been running Ruby on jemalloc 5 without any issues since.
All that's involved is installing your OS's 'jemalloc' package and setting two environment variables (LD_PRELOAD and MALLOC_CONF). Simple enough and more confidence-inspiring than maintaining a patch against a six-year-old frozen dependency if you ask me.
> The pragmatic thing to do is not to prioritize figuring out exactly how Jemalloc 5 works. It's to continue the packaging work to make Ruby + Jemalloc 3 available to the public. Jemalloc 5 can wait.
I disagree about the relative priorities- I spent a day tuning Jemalloc 5 for my team's Ruby application back in 2018 [2] and it's been a done issue for us since then.
[1] https://github.com/jemalloc/jemalloc/blob/dev/TUNING.md
[2] https://github.com/code-dot-org/code-dot-org/pull/24676#issu...
> For reasons that are not yet clear, significant memory savings are only achieved with Jemalloc 3, not with Jemalloc 5.
So the real advantage of this package is that it bundles a 6+ year-old, unsupported version of Jemalloc, because the more recent versions found in current OS distributions don't yield memory savings in practice- for unknown reasons. This doesn't instill very much confidence.
I would be much more excited by efforts to investigate the jemalloc > 3.x changes so Ruby can work optimally with current releases packaged in modern Linux distributions, rather than double-down on a workaround that requires bundling an increasingly-ancient version of the software.
I should also add - as mentioned by the jemalloc author [1], the addition of the time-based purging feature is likely responsible for memory-usage differences between jemalloc 3.x and 5.x, so you can reduce `dirty_decay_ms` and `muzzy_decay_ms` to get 3.x-like memory usage. I have been using this configuration in production since 2018 for significant memory savings in Ruby using jemalloc 5.x.
The real argument is that installing jemalloc separately and running Ruby with an environment variable is too hard.
Backblaze has been offering their 'unlimited data' for over a decade [1], and it hasn't ended badly for them yet.
It's fully sustainable because they only lose money on a few customers (like that one customer storing 430TB for $6/month [2]), while most customers use much less storage than that, so the service remains profitable overall.
The soft limit of its 'unlimited' comes from it being a personal-backup mirroring service and not a fully-external cloud storage, so the service only fits certain use cases.
[1] https://www.backblaze.com/blog/all-in-on-unlimited-backup/
[2] https://www.reddit.com/r/IAmA/comments/b6lbew/were_the_backb...
Trademarks are published for opposition for this reason, right? Client could have filed an opposition against the confusingly similar mark during the opposition period and it never would have ended up in that situation with trademark C. Monitoring trademarks posted to the Official Gazette is an extra burden but important if your brand is valuable.
"Recently, I blogged about building LLVM in 90 seconds [1] using AWS Lambda and my Llama project."
Note that CA law requires employers to provide salary ranges upon request after any initial interview. So not knowing a salary range for a posted position is no excuse, unless you plan on excluding CA from your remote position as well.