AWS availability zones (so like us-west-2b rather than us-west-2) are not the same between accounts. us-west-2b for you is something different than us-west-2b for everyone else.
This is very nonambitious, but I’d love to see a Clojure with less LISP. That is - something like JS syntax but with immutable by default types and const only bindings. Macros would be great too, even if they require a different compilation mode. Top it off with great standard library that has _all_ the collection operations you’ll ever need (e.g. partition-all and dedupe in Clojure). nREPL support or the like is a hard requirement.
Spending the last 6 years writing Clojure has been great. That said, the parens don’t add positively to the experience. They feel like semicolons in C - “the compiler is too dumb to understand this so I have to help it.”
I'm wondering if that has to do with the time spent writing Clojure code?
I have only wrote LISP code during uni and on pet projects and I always feel like the parentheses are making things easier to visually process. The AST is explicit and basically just before my eyes, and it looks nice because of the functional style.
did you try structural editing and using keyboard shortcuts to select, cut and paste the whole inner contents of a parens scope? for my that made the whole difference and I never found such a similar good feel in other languages.
Fair to mention dart (flutter) in VSCode has a refactoring option which removes, adds and modifies all widgets but it falls short in comparison to lisp.
Structural editing is basically a hard requirement with Clojure - I don't think you can realistically live without it. Paredit is fine, but it does take 2-3 months for your fingers to adapt. It would be even better if they didn't have to though.
My sense that is that any written record (especially publicly posted records), an admittance of guilt can later be used as evidence in court. That is, if the bar needs to defend itself in court later, admitting guilt now would make that a lot harder.
And they're a bunch of lawyers -- they likely know that.
Java the language? Very likely not. As proof - a majority of Clojure runs in JavaScript without any code changes (via ClojureScript). That said exceptions tend to look like Java classes, so you’ll definitely see Java bits.
Java the JVM? You _probably_ don’t need to know it to get started, but you’ll have to get familiar with JVM deployment, dependency management, packaging, JVM memory settings, etc if you want to run something outside your dev machine. Getting to 90% here is pretty easy, but the last 10% (to me at least) tends to feel a lot more difficult that other languages.
As a small pro-tip: use jstack. I wish every language came with a jstack. It just dumps the stack traces of all threads of a program by pid.
My experience with ClojureScript is you absolutely have to know the host environment because you will encounter type errors and the maintainers have negative interest in making them clear to users (as in flatly refused offers to contribute changes to make those errors easier to understand).
There is nothing worse than library or language maintainers who do not understand that "pure" error messages are absolute hell. If 99.99 % of the time a user should simply write x instead of y, the message should absolutely state that if possible.
Aren’t those usually capitalized as well? I’ve always though that style in legal texts means “a proper noun defined previously” - in case of plaintiff and defendant, probably on the first page. That said I have no legal background so take that with a grain of salt.
They would appear capitalised on the cover page, not generally in text.
Here is a recent example from a 2022 SCOTUS opinion.
"In rejecting petitioners’ allegations, the Seventh Circuit did not apply Tibble’s guidance. [...] The court determined that respondents had provided an adequate array of choices, including “the types of funds plaintiffs wanted (low-cost index funds).”"[0]
By contrast, a decision of the High Court of Australia:
"The appellants applied to the Supreme Court of New South Wales for orders
that the third respondent, a former director of Arrium, appear for examination and
produce documents. Orders were also sought for the second respondent (the
auditor) and the bank who advised on the capital raising to produce certain
documents.[1]
Yep and covered entities are usually related to billing for medical care. As an example, almost all life insurance companies are not even hipaa compliant because they aren’t covered entities.
In net - hipaa doesn’t protect medical information generally - only the subset that’s usually visible to doctors. And even then, it stops working as soon as the info is outside a covered entity.
Admittedly this is armchair architecture talk, but it seems like either consul or Roblox's use of Consul is falling into a CAP-trap: they are using a CP system when what they need is an eventually-consistent AP system. Granted, the use of consul seems heterogenous, but it seems like the main root cause was service discovery. And service discovery loves stale data.
Service discovery largely doesn't change that often. Especially in an outage where a lot of things that churn service discovery are disabled (e.g. deploys), returning stale responses should work fine. There's a reason DNS works this way - it prioritizes having any response, even if stale, since most DNS entries don't change that frequently. That said, DNS is not a great service discovery mechanism for other reasons. Not sure if there's an off-the-shelf solution that relies more on fast invalidation rather than distributed consistent stores.
Good catch. If Roblox only uses consul for service discovery, things should continue to work, just slowly degrade over the hours/days. There should at least be one consul agent running on each physical hosts, and this consul agent has cache and can continue to provide service discovery functionality with stale data.
Dissecting this paragraph from the post-mortem...
> When a Roblox service wants to talk to another service, it relies on Consul to have up-to-date knowledge of the location of the service it wants to talk to.
OK.
> However, if Consul is unhealthy, servers struggle to connect.
Why? The local "client-side" consul agents running on each hosts should be the authoritative source for service discovery, not the "server-side" consul agents running on the 5 voter nodes.
> Furthermore, Nomad and Vault rely on Consul, so when Consul is unhealthy, the system cannot schedule new containers or retrieve production secrets used for authentication.
Now that's one very bad setup, similar to deploying all services in a single k8s cluster.
Didn’t realize consul had that. Seems like the right approach - though I wonder why Roblox wasn’t using it.
Fwiw I believe kubernetes did this right - if you shoot the entire set of leaders, nothing really happens. Yes if containers die they aren’t restarted and things that create new pods (eg cron jobs) won’t run, but you don’t immediately lose cluster connectivity or the (built-in) service discovery. Not to say you can survive az failures or the like - or that kubernetes upgrades are easy/fun.
And don’t run dev stuff in your prod kube cluster. Just…don’t.
Their comment implies "are totally fine with stale data".
Their argument is that the membership set for a service (especially on-prem) doesn't change all that frequently, and even if it's out of date, it's likely that most of the endpoints are still actually servicing the thing you were looking for. That plus client retries and you're often pretty good.
Maybe I'm just working on an idiosyncratic version of the service discovery problem, but "stale data" is basically my bête noire. Part of it is that I don't control all my clients, and I can't guarantee they have sane retry logic; what service discovery tells them is the best place to go had better be responsive, or we're effectively having an outage. For us, service discovery is exquisitely sensitive to stale data.
I'm not saying I totally agree with the original comment there, just confirming that they meant it.
If you own your clients, sometimes you can say "it's on you to retry" (deadlines and retries are effectively mandatory, and often automatic, at Google). Having user facing services hand out bad addresses / endpoints would be really bad.
However, even for things like databases, you really want to know who the leader / primary is (and it's not really okay to get a stale answer).
So I dunno, some things are just fine with it, and some aren't. It's better if it just works :). Besides, if the data isn't changing, the write rate isn't high!
Yes - exactly what boulos said - I’m coming from the Google “you control your clients” perspective. That said, in some sense you always control your clients - you can always set up localhost proxies that speak your protocol or just tcp proxies.
The thing is service discovery is _always_ inconsistent. By the time you get your set of endpoints from your discovery, it can be out of date by the time you open your socket. Certainly for something like databases you need followers or standby leaders to reject writes from clients - service discovery can’t 100% save you here.
In case you haven’t seen it - the TreasuryDirect password policy is almost comical. There’s a screenshot in the repo.
The website disables the password input field (and password managers with it). To “type” your password, you have to use some on screen button-based keyboard monstrosity.
If someone wanted to make fun of password rules, this would have been great satire. But no - this is actually how you buy bonds from the US treasury.
One of the hardest types of queries in a lot of DBs is the simple `min-by` or `max-by` queries - e.g. "find the most recent post for each user." Seems like Postgres has a solution - `DISTINCT ON` - though personally I've always been a fan of how BigQuery does it: `ARRAY_AGG`. e.g.
SELECT user_id, ARRAY_AGG(STRUCT(post_id, text, timestamp) ORDER BY timestamp DESC LIMIT 1)[SAFE_OFFSET(0)].*
FROM posts
GROUP BY user_id
`DISTINCT ON` feels like a hack and doesn't cleanly fit into the SQL execution framework (e.g. you can't run a window function on the result without using subqueries). This feels cleaner, but I'm not actually aware of any other DBMS that supports `ARRAY_AGG` with `LIMIT`.
I would use lateral join. Alternatively you can use window function instead of lateral join, buy from my experience lateral joins are usually faster for this kind of top-N queries in postgres.
I assume you mean `ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...) as row_number` with a `WHERE row_number = 1`. We ran into issues with memory usage (i.e. queries erroring because of too high memory usage).
The `ARRAY_AGG` approach uses a simple heap, so it's as efficient as MIN/MAX because it can be computed in parallel. ROW_NUMBER however needs all the rows on one machine to number them properly. ARRAY_AGG combination is associative whereas ROW_NUMBER combination isn't.
FFmpeg is licensed under LGPL which can (albeit carefully) work on the web, but libx264 is GPL. I think that alone makes this project unusable in non-open-source projects? (For reference, GPL does not have any dynamic linking exception, so the copyleft terms apply as soon as you include it in your shipped binary in any way)
Aside from the OSS licenses alone, H.264 encoders/decoders have a required patent license. Most users get around this by using an API (e.g. `<video>` tags, AVFoundation) - which means Google/Apple pay for it when they ship the decoder for Chrome/iOS. How does this project get around that requirement?
> I think that alone makes this project unusable in non-open-source projects?
I hope so. I mean, that's the only reason for GPL to exist, right? There's quite a few proprietary programs that decided to relicense as GPL in order to use a GPL library.
IANAL but you don't need to relicense your program to GPL just to use a GPL library. You can relicense to something that is compatible with GPL, like say the MIT license. Then the combined form has to be distributed under GPL terms. But when you one day replace the library with something not under GPL, you can distribute combined forms of those under MIT.
That is correct. If you want to redistribute a mixture of different program components as one program, all the pieces have to have licenses that are compatible. If any of them are GPL, then the whole thing will be GPL; all the other licenses have to be cool with being part of a whole that carries a GPL umbrella license. MIT and BSD pieces are this way.
I think the original point of GPL was to incentivise companies/developers to contribute changes back to GPL licensed project. What is clear is that, minus a few exceptions, most large open source engaged companies avoid GPL because of the risk of compliance [1]. And many authors that originally licensed their projects as GPL see this and regret their choice [2][3]. This is why there is a trend away from copyleft licenses [4].
No, that was the point of LGPL (Lesser or Library GPL)
The point of GPL software is that it's to be used in a GPL system, where users retain modification rights to the system they've acquired, and to prevent proprietary systems from free-loading off of GPL work.
Even LGPL seems to have quite some FUD around the compatibility with distributing resulting software in app stores.
This seems to be quite at odds with the (maybe mistaken?) idea of a license that allows embedding a component without "license contaminating" the entire project, but still requires publishing changes to the component itself.
I wonder if there is a license that actually achieves that, without restricting the ability to publish to app stores?
There’s the philosophical intent of the FSF and then there’s what individual project authors intended by adopting GPL.
I think OP correctly explains the perspective of some/many/or even most authors.
Arguably, given the decline of GPL as the de facto license for OSS might indicate this viewpoint is at least an accurate perspective today and may have been the underlying truth all along. Certainly growing up I think I cared more about the concept of contributing improvements back than necessarily being able to have source to all derivative products and didn’t trust corporations to give back (I still don’t, but the situation doesn’t seem quite so serious for most projects).
That's just one point; but note that the LGPL also ensures that users retain those rights.
Yet here is a difference between the GPL and LGPL.
A GPLed piece cannot be mixed together pieces that have incompatible licenses.
This is true even if the pieces are mixed together in a dynamic way that respects their boundaries, so that users can rebuild the GPL-ed piece from sources, make modifications, and slide the modified piece back into the combination.
This is part of the point of the GPL, and specifically that point which is relaxed by the Lesser GPL, which is called "lesser" for some ideological reason.
Most "most large open source engaged companies " want to leach off open source and do not want to create end user products that are open source.
They focus on open source development tools, and libraries. Not end-user software products.
This is why they reject GPL because they want to be able to use the Tools and Libraries to package up a commercial software to sell to end users.
They do not actually support the principles of Free Software, it is simply away for them to lower development costs and off shift capital expenses while getting some good PR about being "open source engaged"
What’s also important to know is that the commercial license (IIRC) doesn’t include access to the patent pool. I presume that when going through the commercial license the x264/x265 people will walk you through or otherwise assist in the MPEG-LA stuff:
It trips people up: the commercial x264/x265 license provides alternate use terms on the implementation. The implementation, however, is still protected by various patents worldwide and MPEG-LA is who you go through for access to the patent pool which is (supposed to) include payment to all of the identified patent holders.
That is true but if you’re using libx264/libx265 you’re not using hardware encode/decode blocks that include the patent license so MPEG-LA is back in the picture.
Again IANAL but license are per devices and not per IP blocks so you dont double pay for each and every components ( Hardware Encode Decode in CPU and GPU ). And generally speaking that is up to the OEM and Devices Manufactures to have it done.
It is almost as if JavaScript/WebAssembly need a sandboxing feature that allows a library to be LGPL (or GPL?) compatible - legally callable from your own JavaScript source code.
I wonder if a legal sandboxing feature could be designed, perhaps even misusing the technical words to munge the sandbox to be compatible? Misuse words like header file, Library, link, object code etcetera to make the sandbox legally compatible?
It's a problem if your IDE is designed to work only with gcc. It's not a problem, if it could work with any compiler and gcc is just one of the options.
My understanding is that it matters whether the GPL software is distributed with your program. If your IDE installed gcc, you would have to license it as GPL — even if it also installed other compilers. (It would be fine for your IDE to use a preexisting gcc installation obtained in some other fashion, though).
If I was a copyright lawyer, I would probably take a dim view of a defense that amounts to "it's not using your client's code, it's using code that directly uses your client's code."
My understanding of the AGPL and its history is that it was meant to close a perceived loophole with SaaS: companies selling you access to services built on GPL'd code were not compelled to distribute their changes.
The is significantly different a local virtual machine, of which the JVM is one: the code is still fundamentally being distributed to the client, which triggers the release clause in the original GPL. To the best of my knowledge, nobody has ever (successfully) claimed that executing JVM bytecode releases them from their obligations under the GPL.
My understanding of GHE is that it uses libgit2 internally, which in turn has a linking exception in its license (just like GCC and glibc). It’s unlikely that they’re violating GPL in that particular way.
GitHub Enterprise is proprietary software. To the best of my (external observer's) knowledge, it has no GPL code in it. If it does, then that's probably a licensing violation, but IANAL.
As I (not a lawyer) understand it, the spectrum here is tight/loose binding on a conceptual level, rather than the specific technology used to achieve it.
The static/dynamic linking concern seems like a red herring, as it reflects a specific technological instance of such a distinction, but in architectures that do linking differently than traditional Unix systems, it makes less and less sense.
Meh, you don't need any special features to use LGPL libs. As long as the user can recompile and swap out that library with their new version, you're done. This either means dynamic linking the library or making object files for your proprietary code available so that the user can link it.
