I recognize that Bluesky is at present more open than Twitter and that all of the necessary building blocks for the infra are publicly available. That's good of course.
However I think the view you expressed there is misguided. If Bluesky locked out third party infra tomorrow presumably the vast majority of people would not move. Thus vendor lockin via network effects remains. (Ie you are always free to leave but you'd be moving from a metropolis to a backwater.)
The only scenario where this isn't true is one where no more than a few percent of the people you interact with reside on any given node. By that metric small AP nodes pass while large ones such as the flagship Mastodon node fail. Similarly Gmail and Outlook fail while any self hosted mail server passes.
It's important to keep separate the parts of the security model mobile did well from the parts it got wrong. Declaring that app developers can decline end user access to app files is unacceptable. I get final say on my device. I get to run as root. Hell, I get to run as ring 0 if that's what I want to do.
IMO, the developers choose what software they want to write. If Microsoft Word decided to remove the "export to PDF" feature, that would be their right. And it would be your right to stop using Microsoft Word. If you want to be root on your system, you are free to install a system that gives you root access.
And that's the part that I believe should be a right: if you buy a smartphone, you own that piece of hardware, and you should be able to install the system you want. But if you are not the one developing that system, you don't get to decide what this system does. Just like you don't get to decide whether Microsoft Word can export to PDF or not.
If they use paid accounts I would expect them to strip info automatically. An "obvious" way to do that is to diff the output from two separate accounts on separate hardware connecting from separate regions. Streaming services commonly employ per-session randomized stenographic watermarks to thwart such tactics. Thus we should expect major publishers to do so as well.
At which point we still lack a satisfactory answer to the question. Just how is archive.today reliably bypassing paywalls on short notice? If it's via paid accounts you would expect they would burn accounts at an unsustainable rate.
Irrelevant to a determination of fact, yes. But very relevant to the question of whether or not I care about any of this. Bad thing happened to bad person, lots of drama ensued, come rubberneck the various internet slapfights, details at 11. In other news, water is wet.
I'm not entirely clear what your goals are but roughly, just figure out an application that holds your interest and build a model for it from scratch. Probably don't start with an LLM though. Same as for anything else really. If you're interest in computer graphics then decide on a small scale project and go build it from scratch. Etc.
Aren't decent GPU boxes in excess of $5 per hour? At $0.20 per kWhr (which is on the high side in the US) running a 1 kW workstation 24/7 would work out to the same price as 1 hour of GPU time.
The issue you'll actually run into is that most residential housing isn't wired for more than ~2kW per room.
Is that with a WISP by chance? Or in a developing country? Or are there really wired providers with such low caps in the western world in this day and age?
ATT once told me if I don't pay for their TV service then my home gigabit fiber would have a 1TB cap. They had an agreement with the apartment building so I had no other choice of provider.
> Aside from the fact that 1-based indexing is better for scientific code
I find it to be substantially worse. It's fine as long as you don't manipulate the indicies. But as soon as you start doing math on them 1 based becomes a headache (at least IME).
Meanwhile all you get in exchange (at least as far as I can tell) is ease of speaking about them in natural language. But I'm not usually conversing about indicies.
Concise range notations are a mixed bag. There's pros and cons to either scheme there as far as the syntax goes.
Presumably inertia and ecosystem size (but that's a follow on of inertia). When Julia came out Python already had traction for ~most things.
Keep in mind that it went with 1 based indexes to make the switch easy for Matlab types. I'm not sure if that was a good or bad move for the long term. I'm sure it got some people to move who otherwise wouldn't have but conversely there are also people like me who rejected it outright as a result (after suffering at the hands of 1 based indexing in Matlab I will never touch those again if I have any say in the matter).
I've considered switching to it a few times since seeing that they added variable indexes but Python works well enough. Honestly if I were going to the trouble of switching I'd much rather use Common Lisp or R5RS. The nearest miss for me is probably Chicken, where you can seamlessly inline C code but (fatally) not C++ templates.
If I ever encounter "Chicken, except Rust" I will probably switch to that for most things.
That's part of the answer, but there's a bit more to it IMO.
The syntax is a bit weird; python, swift, rust, and zig feel more parsimonious.
I absolutely love multimethods, but I think the language would have been better served by non-symmetric multimethods (rather than the symmetric multimethods which are used). The reason is that symmetric multimethods require a PHD-level compiler implementation. That, in turn, means a developer can't easily picture what the compiler is doing in any given situation. By contrast, had the language designers used asymmetric multimethods (where argument position affects type checking), compilation becomes trivial -- in particular, easily allowing separate compilation. You already know how: it's the draw shapes trick i.e., double-dispatch. So in this case, it's trivial to keep what compiler is "doing" in your head. (Of course, the compiler is free to use clever tricks, such as dispatch tables, to speed things up.)
The aforementioned interacts sensitively with JIT compilation, with the net outcome that it's reportedly difficult to predict the performance of a snippet of Julia code.
1. I use the term "performance" slightly vaguely. It's comprised of two distinct things: the time it takes to compile the code, and the execution time. The issue is the compilation time: there are certain cases where it's exponential in the number of types which could unify with the callsite's type params.
2. IIRC, Julia compiler has heuristics to ensure things don't explode for common cases. If I'm not mistaken, not only do compile times explode, but certain (very common) things don't even typecheck. There's an excellent video about it by the designer of the language, Jeff Bezanson -- https://www.youtube.com/watch?v=TPuJsgyu87U . Note: Julia experts, please correct me if this has been fixed.
3. The difficulty in intuiting which combinations of types will unify at a given callsite isn't theoretical; there are reports of libraries which unexpectedly fail to work together. I want to qualify this statement: Julia is light years ahead of any language lacking multimethods when it comes to library composability. But my guess is that those problems would be reduced with non-symmetric multimethods.
4. The non-symmetric multimethod system I'm "proposing" isn't my idea. They are referred to variously as encapsulated or parasitic multimethods. See http://lucacardelli.name/Papers/Binary.pdf
I have huge respect for Jeff Bezanson, for the record!
However I think the view you expressed there is misguided. If Bluesky locked out third party infra tomorrow presumably the vast majority of people would not move. Thus vendor lockin via network effects remains. (Ie you are always free to leave but you'd be moving from a metropolis to a backwater.)
The only scenario where this isn't true is one where no more than a few percent of the people you interact with reside on any given node. By that metric small AP nodes pass while large ones such as the flagship Mastodon node fail. Similarly Gmail and Outlook fail while any self hosted mail server passes.
It's not an easy problem to solve.
reply