Free air is very common these days. I don't think a purchase has ever been required for free air anywhere I've been. Occasionally you need to go in and get a free token since the air machine is still coin operated, but I've never been asked to prove a purchase.
I've heard this called a "dancing bear" before. It's interesting because it's a bear dancing, not because the dancing is any good.
These conversations get frustrating since one group is saying the dancing is bad, a second group is saying it's good (for a bear), and a third group is saying we are a few years from a bear-only dancing industry.
The hype train the caught me was VR. I'm reminded of the Microsoft Hololens. It was an incredible feat of engineering. At the same time, it was--at times, literally--a painful experience.
There was a vision of the Hololens being a general purpose compute device that enabled something more like the power of a desktop without being tethered to a sitting position at a desk. You could see it if you squinted hard (incidentally, the device caused a lot of eye strain). But even at the height of the VR hype cycle, I didn't know anyone pushing the Hololens on anyone. Nobody was telling the world they were going to be using Hololenses v1 or v2 as their only computer "or get left behind."
In the first paragraph (either of chapter 1 or the prologue), not at all. It's pulling everything from pre-training, so it is likely relying just as much on all the visual mediums like the Peter Jackson films, the animated The Hobbit (1977), and all kinds of random depictions of Tolkien's works.
Bilbo's house is actually described in The Hobbit and the exterior isn't really described at all in Fellowship. The prologue of Fellowship (Concerning Hobbits) mentions hobbits like round doors and windows and the fact some hobbit homes are underground, but the turf-dome design here is not mentioned. It actually mentions hobbit homes typically have bulging walls, so unless you've read the The Hobbit, you might not picture this entirely-underground style.
In The Hobbit, his home is described as a (nice) hole in "The Hill" with a perfectly round front door and round windows, which could imply the design here.
Right, yeah I asked because I assumed it copied the look from the movie. I think it'd be more interesting to do this for something that hadn't been adapted (yet). The first chapter of Neuromancer perhaps
I think you could use the two shafts to align and attach the mounting bracket by drilling two holes the proper distance apart. Drilling holes is pretty easy compared to cutting straight lines and I think most people are more likely to have a drill. If you use a piece of wood, the additional thickness can help the shafts to keep the wood perpendicular. You might not need any additional fastener, and the lack of fastener could help it return to a neutral position after operation rather than migrate. Also, slowing down the stepper motor can reduce unnecessary forces and the likelihood of malfunction.
As long as it's some automated signal, the User-Agent can use any logic it wants to send it without cooperation. The specifics of how to send the signal don't have to be legislated. E.g. Firefox's Tracking Protection has a global default a site-specific overrides, so it's very likely that they would do the same for this or just combine those features.
Is there any evidence of division? Are all the vibe-coders going to some codeberg2? One of the main complaints is that the banned projects don't have human users proportionate to their activity, so if they all go to codeberg2, then that forge would just be full of projects nobody cares about.
Are there any projects on codeberg that are getting banned and actually have significant human interest?
If codeberg decided to kick out spammers, nobody would decry the loss, so what's being lost here? Is it strictly slippery slope?
Nobody has been banned yet, AFAIK. So nobody can answer your second paragraph question. But plenty are choosing to leave.
The judgement you're talking about here ("banned projects don't have human users propostionate...") is going to require evidence? At this point the software community is absolutely full of these tools and people who use them.
If the specific thing banned was projects like that, fine. But that's not what the clause added in the PR said.
TFA says the whole codebase is 600k, so that would be 1.8% dead code. IME dead code is much more common in larger codebases as figuring out that code is dead becomes more non-local and changes over time create dead code at a distance. I'm also not sure if the 11k was trivially dead (`if (false) { dead_code(); }`) or if it was more subtle (e.g. dynamically-dispatchable code that can't logically be called).
The 1.8% feels high if it's trivially dead. When I've run simple static analysis on decent codebases before, it's been much lower. For non-trivial dead code, it might be low. E.g. a lot of projects have piles of "dead" code behind ancient feature flags that would never be switched.
A small amount of dead code is fine. E.g. it might not be worth deleting utility methods that you happen to remove the last use of if they are simple and you might re-add a use later. Generated code is often dead since it's not worth specifying to the generator exactly what will be used. Other times, deleting dead code can lead to a valuable cascade of other deletions and simplifications.
LLMs from 1+ years ago approached solving every problem by adding additional code and not cleaning up or adding strange unnecessary backwards compatibility (and often still do this kind of thing - "all tests green")
java.lang.String and other types don't extend JsonValue, and java lacks any trait-like way to add this functionality to existing types, so you would have to change the signature to this:
Now you can pass any Object in, but the typechecker can't ensure that it is convertible to json anymore. I.e. it will have to check at runtime that it's either JsonValue or another type that is has a known conversion for (Integer, Double, String, List, Map, etc.). The jackson ObjectMapper e.g. has a lot of configuration available to tell it how to do these conversions on arbitrary types, and I think they want to eliminate that kind of ceremony.
It does seem like any serious application is going to use another library, and this will be useful for very simple json usage or single-file hello-world type programs (e.g. to go along with Implicitly Defined Classes and the Flexible Launch Protocol).
A Modest Proposal that will never be implemented: add an interface to String, Boolean, Integer, Long, Float and Double. Because all these types already implement "toString" (and I believe their toString representations are compatible with JSON), it can be a pure marker interface.
> I believe their toString representations are compatible with JSON
Not quite. String is the big problem, since it needs to be wrapped in quotes, and special characters need to be escaped. But Float and Double are also problematic because Infinity and NaN aren't representable in json.
However, the new interface could have a "toJsonString" or maybe even a toJson method that returns a JsonValue
For the "quick one-off script" case (where Implicitly Declared Classes shine), I think the most galling ceremony in this example is explicitly converting all N items in a list of literals into JsonValues for JsonArray.
The system the fight is in experiences time-dilation, where everything slows down to 10% speed or even less. However, a few effects create a positive feedback loop that makes the problem worse.
All the surrounding systems still run at full speed. You can travel large distances and still arrive soon enough to matter in the fight. You can also die, respawn in another system, rejoin the fight, and barely miss anything. The positions in the fight therefore move even slower than time-dilation since ships on both sides are replaced so quickly.
Large groups have a massive advantage over small groups, so alliances are very large and join various alliances-of-alliances. The playerbase is often organized into only 2-3 major coalitions. At some points in history, nearly all the alliances have joined the same coalition, which leads to a strange pax-Romana called the "blue donut" (referring to all the ownable outer-systems being "blue" or allied with each other).
Also, nearly every player in a large fight just follows simple orders. Orbit A and shoot B. There are just a few people calling the shots.
Fights sometimes end just because people are bored, need to sleep, or go to work.
That's interesting, although "read committed" here would be different from the isolation level of the same name. It seems really tricky to implement since tuples could be removed during a query. E.g. the backend could fail to chase tuple-id pointers, and there would be cases where it can be difficult to ensure a tuple is returned exactly once for a given scan.
If you use ordinary READ COMMITTED transactions, they will advance their xmin horizons on each query (and allow old version cleanups) up until their own transaction id but unfortunately not beyond that. For a given table, this is important since that transaction is uncommitted and it might modify the table. If you could make long-running transactions readonly on those specific tables, then you could use a different xmin horizon specifically for those tables. It would require a lot of duplicative bookkeeping in shared memory though. You could probably fake this today by using 2 databases on the same machine and using two-phase-commit+dblink/fdw for cross-database transactions/queries (fdw uses repeatable read in transactions, so it won't allow the xmin to advance).
