jsmith45

Block based automated signaling can technically be implemented as a primarily local system. Each block needs to know if there is a train in itself block (in which case all block entrance signals must show stop, and approach signals indicate that they can be entered, but the train must be slowing, so it can come to a stop by the block entrance signal). It must also know about a few preceeding blocks for each path leading into it, so as to know which contain trains that might be trying to enter this block, so it can select at most one to be given the proceed signal, and others to be told to brake to stop in time for the entrance signal. While it is nice if it knows the intended routes of each train so it can favor giving the proceed indicator to a train that actually wants to enter it, but if it lacks that information, then giving the indication to a train that will end up using points to take a different path doesn't hurt safety, just efficiency.

Of course, centralized signaling is better, allowing for greater efficiency, helps dispatch keep track better track of the trains, makes handling malfunctioning signals a lot safer, among many other benefits. But it doesn't mean local signaling can't be done.

Why would this be? I'm probably missing something.

Don't these LLMs fundamentally work by outputting a vector of all possible tokens and strengths assigned to each, which is sampled via some form of sampler (that typically implements some softmax variant, and then picks a random output form that distribution), which now becomes the newest input token, repeat until some limit is hit, or an end of output token is selected?

I don't see why limiting that sampling to the set of valid tokens to fit a grammar should be harmful vs repeated generation until you get something that fits your grammar. (Assuming identical input to both processes.) This is especially the case if you maintain the relative probability of valid (per grammar) tokens in the restricted sampling. If one lets the relative probabilities change substantially, then I could see that giving worse results.

Now, I could certainly imagine blindsiding the LLM with output restrictions when it is expecting to be able to give a freeform response might give worse results than if one prompts it to give output in that format without restricting it. (Simply because forcing an output that is not natural and not a good fit for training can mean the LLM will struggle with creating good output.) I'd imagine the best results likely come from both textually prompting it to give output in your desired format, plus constraining the output to prevent it from accidentally going off the rails.

> Actual CS research is largely the same as EE research: very, very heavy on math and very difficult to do without studying a lot.

That is largely true of academic research. A critical difference though is that you don't need big expensive hardware, or the like to follow along with large portions of the cutting edge CS research. There are some exceptions like cutting edge AI training work super expensive equipment or large cloud expenditures, but tons of other cutting edge CS research can run even on a fairly low-end laptop just fine.

It is also true that plenty of software innovation is not even tied to CS style academic research. Experimenting with what sort of perf becomes possible via implementing a new kernel feature, can be very important research but isn't always super closely tied to academic CS research.

Even the more hobbyist level cutting edge research for EE will have more costs, simply because components and PCBs are not exactly free, and you cannot just keep using the same boards for every project for several years like you can with a PC.

Historically from a revenue perspective essentially all the tarrif revenue came from bulk imports (trucks, ships, etc).

It is important to also capture tarrifs from high value parcels, as for small but high value items a parcel can very much be a similar bulk import. (Picture diamonds. A moderate sized parcel full of them is very much a bulk import).

But at the same time trying to collect tarrifs on every parcel was historically deemed non-viable. Way too much work for too little gain. Especially since historically, the addressee of the parcel often ends up paying the tarrif, this requiring customs to communicate this to the parcel carriers broker, who must communicate it and collect from the end customer, who finally gives the money to the broker, who submits it to the government. Meanwhile CBP needs to store this package.

This whole process ends up just annoying your countries own citizens, and generated little revenue, so a de minimis exemption of some form was highly desireable. And to most politicians there seemed like little downside to setting it fairly large. Sure $800 is probably larger than reasonable, but it certainly means the average person would rarely ever need to interact with this process, and that was good enough.

Honestly, I'm here half wondering why we need the click at all. One finger drag for move, quick one finger tap for left click, tap and half for click and drag, two finger tap, two finger drag for scroll covers all the common interactions.

Which isn't to say I don't use the click functionality at all. I will subconciously use it in some scenarios, but not in others, but if it were missing I would adapt very quickly, since I use the gesture alternatives so often, that I would automatically fall back to them.

I suppose I need the click for some obscure interactions like right click drag, but honestly except in games I've almost never seen that used. My surface laptop as currently configured literally wouldn't even allow some other rare ones like hold button and scroll (I'd need to turn on right side scroll-wheel for that) and I've never even noticed the absence of that ability until I tried it just now.

I'm confused.

$XDG_CONFIG_HOME is clearly meant for data that would otherwise be in a configuration style dotfile. This is the sort of configuration that that users may well want to sync between machines such that a dotfile manager should include them by default. (That said, there may be some data from some of the other XDG directories worth syncing too, but generally a dotfile manager should not include those other folders in full by default.)

Beyond that the spec defines $XDG_DATA_HOME as "base directory relative to which user-specific data files should be stored.". The default path ($HOME/.local/share) might suggest that this should be read-only data, but it actually is read-write.

The description of the $XDG_STATE_HOME makes it quite clear that $XDG_DATA_HOME read-write: "The $XDG_STATE_HOME contains state data that should persist between (application) restarts, but that is not important or portable enough to the user that it should be stored in $XDG_DATA_HOME". This makes it clear that important and portable data should be written to $XDG_DATA_HOME.

And thus we also have $XDG_STATE_HOME. The list of examples that follow the previously quoted sentence make it clear that this is stuff that gets persisted, but if it were omitted from a backup, the user will probably not care too much (i.e. stuff like logs, history, set of open files, undo history, etc.

$CDG_DATA_HOME does also include any read-only reference data, which should be searched for there, and in $XDG_DATA_DIRS (which defaults to "/usr/local/share/:/usr/share/").

It could certainly be argued that read-only reference data and read-write user data should not have been mixed. After all Unix does keep them separate that at the top level `/var` vs `/usr/share`, but the spec authors apparent felt this distinction was not necessary at the user level.

The European Commission's proposed interim solution for age verification (ageverification.dev) is actually pretty good vs the shitshow of the US and UK.

It works like this:

1. You contact an age verification provider (e.g., national eID schemes, banks, or mobile operators) and provide proof of identity, which they will verify possibly against government databases or whatever, etc. Once they confirm your age they will issue you with a bunch of Age attestations. At this point you don't even know where you will use these, so that info literally cannot be sent to the provider. The attestations are a JWT-like envelope with a payload conceptually equivalent to `{"nonce": "LARGE_RANDOM_HEX_STRING", "age_over_18":true}`, signed with the provider's public key. (The actual implementation is more complex).

2. This is stored in a local app, which will guarantee each attestation only gets used once (to avoid linking user across relying sites). There is no special authentication of the app in the protocol with the replying site, so you can write your own. The Commission provides an open source reference app. There is a standard protocol for communicating with verification providers, however it is not mandatory, so using the reference app might not support all verification providers, but should support a variety.

3. When you want to visit some site needing age verification, and you already have a verified account, you just sign in, otherwise, that site will use a standardized protocol to request proof from the app. The app will provide just the attestation token. The relying site does not get any info about your identity, other than the attestation token. Plus of course, the relying party must accept any age verification provider approved by the commission, not just its preferred one. The EC's solution also supports the app providing the relying site a Zero-Knowledge Proof of having such a token, which makes it possible for the relying site to learn the user's identity even if colluding with the age verification provider.

The issue being that if the concept of Parliamentary supremacy as currently understood is maintained then current Parliament cannot bind future Parliament.

The best that Parliament can do under the current definition is things like passing an interpretation law that includes various rules, and which permit courts to strike down other laws that violate these rules, unless said other law amends this one. Then Parliament could propose rules not allowing the government to propose such legislation unless (some conditions), etc. This would be with the intention of future Parliments keeping the rule.

That is all technically fine as long as future Parliament can simply drop the rule by majority vote, and can modify the law by sinple majority vote. But that means this is not really binding, just a relatively modern tradition.

If they tried anyway, a future Parliament (led by a different government) would likely just ignore it citing Parliamentary supremacy, and the courts would almost certainly concur if challenges arise.

For simple tail recursion, expression as a loop is pretty simple, just define the function with the same parameters, and mutate the parameters, possibly creating local copies of the original values if you need the previous value to evaluate another new parameter.

But since your example is relying on mutual tail recursion with functions for each state. Yeah, that is much harder to cleanly map to a simple loop. Like obviously making a giant function to cover all the state functions with a giant switch statement is possible, and even relatively common, but not especially clean.

If all state functions have the same parameters, then an approach with functions per state that return the new state and new parameter values, which get called from a loop using a state value to function dictionary can be relatively clean. But if states need different parameters, yeah that gets complicated.

I'm not sure that it necessarily follows from the overlap they are not linearly independent. As far as I can tell that alone would simply make them non-orthogonal basis vectors.

The issue is more that there isn't really any frequency that only stimulates the M cones. There are some that more or less only stimulate the L cones, but as we get bluer, the stimulation curves of the M and L cones mostly converge, so we can't really get fully independent M cone stimulation (at least not without tricks like locating specific cones and using lasers to stimulate just the M ones, while missing the L ones.) This does indeed make them not linearly independent, so your overall point still stands.

Yeah, while large portions of the online logic puzzle communities tend to agree that puzzles should not require backtracking (after all one can often trivialize the intended logical solve path like that), it has proven difficult to define what should count as backtracking vs a simple obvious contradiction that should count as a logical step.

Ability to visualize it in your head, without needing to copy the board, or make temporary marks is certainly not unreasonable for complicated puzzles. That is the same rule as Simon uses for logic puzzles (mostly variant sudoku) on the YouTube channel Cracking the Cryptic.

It isn't the most satisfying way to delineate the dividing line, since how much a person can track in their head can vary, but coming up with other rules can be absurdly tricky. Especially if one wants to make a set of rules applicable to multiple types of logic puzzles. After all simple two to three step contradictions may be unusually powerful for some types of logic puzzles, while they can be the basic deduction type for a different one.

That can vary. A fair number of institutions would consider an undergrad paper that consisted mostly of cited quotations, with only a small amount of original analysis and conclusion drawing to be a form of plagiarism, even while a similar paper that paraphrases many of the cited works might be more acceptable, especially if the paraphrasing was adding value, like standardizing equivalent terminology between the sources (ideally including footnotes about what each author originally called each concept).

Other institutions do hold more of a view that plagiarism is not possible with credit, but they will then consider the first mentioned paper as some other form of academic violation.

Even the narrow definition institutions don't view plagiarism purely as misrepresenting sources of ideas as yourself, or self-plagiarism would not be a thing. It ends up as something more like: passing off original ideas from another work as having originated in this current work.

The whole point of the study is to show the limitations of a Randomized Controlled trial.

This study shows the difficulty in studying the effectiveness of entrenched practices, especially when there is good reason to suspect that not using the practice will result in extremely significant harm at high probability. Here we have a study with enormous self-selection bias.

They did ask candidates mid-flight in commercial aircraft if they would be willing to participate at their current altitude and speed, and obviously all declined. On the other hand a number of candidates found on private planes that were not moving were willing to participate.

This study also shows how statistical techniques can be misused, as here in a study where the adverse results in question occurred in literally zero participants of the control group is obviously worthless, but one can still run the stats to conclude no statistically significant difference was detected.

Lastly it brings up questions about best available evidence. Many researchers tend to automatically assume that an RCT is better than other evidence. Now if they read the study closely and notice flaws they often change their mind, but if they just skim the abstract they can miss this. This is an example of a case where the only available RCT is total garbage, and we have far better evidence in the form of accident statistics from skydivers. Accidents where no chute was packed, or the chute (and any backups) completely fail to deploy are a very good proxy in practice for jumping without one at all.

If it ignores the parameter values, then how does it estimate cardinality? Does it optimize for the worst case scenario (which runs the risk of choosing join implementations that requiring far more data from other tables than makes sense if the parameters are such that only a few rows are returned from the base table), or does it assume a row volume for a more average parameter, which risks long running time or timeouts if the parameter happens to be an outlier?

Consider that Microsoft SQL Server for example, does cache query plans ignoring parameters for the purposes of caching (and will auto-parameterize queries by default), but SQL Server uses the parameter value to estimate cardinalities (and thus join types, etc) when first creating the plan, under the assumption that the first parameters it sees for this query are reasonably representative of future parameters.

That approach can work, but if the first query it sees has outlier parameter values, it may cache a plan that is terrible for more common values, and users may have preferred the plan for the more typical values. Of course, it can be the reverse, where users want the plan that handles the outliers well, because that specific plan is still good enough with the more common values.

Looking though that list:

    All of the system fonts

Presumably the source included the TTF files from which the rasterized bitmap resources were automatically generated. Including the pre-rasterized bitmaps extracted from a previous release should not be a problem as typefaces and bitmap fonts are not subject to copyright in the US, vs vector font files which are eligible for copyright as computer programs.

    The Bluetooth stack, except for a stub that will function in an emulator

This seems unfortunate, and looks to be one of the most critical gaps in the source release.

    The STM peripheral library

You can get this from ST no problem, although it is only licensed for use on STM devices.

    The voice codec

It should be feasible enough to replace this.

    ARM CMSIS

The old versions with non-free licenses are still available from ARM or ST, and the recent versions are Apache licensed (but some porting of code might be required to use to newer versions).

    For the Pebble 2 HR, the heart rate monitor driver

This was probably based on sample code from the vendor which could be replaced.

2013ish also had a "One" naming trend that was short lived: Xbox One SkyDrive->OneDrive

It didn't seem to spread much though...

Honestly, health insurance has a lot wrong. Things like the 80/20 rule can create some weird incentives. Normally an insururer would want to minimize the costs of what they insure, but if non-claim overheads plus profit has reached 20%, then they can't negotiate lower costs without losing profit, and are actually incentivized to either get more claims or negotiate worse prices.

This is besides all the inefficiencies, and nonsense. For example even if a patent hypothetically knew exactly how long a procedure would go, exactly what personnel would be involed and how, exactly how much anesthesia/sutures/other billable supplies were used, and that there were no complications, and even if they know that no denial of coverage would happen, it is not structurally possible for them to know the out of pocket costs, except for the handful of surgeries that get treated as package deals. It would literally take dozens of hours of phone-calls to the hospital's and each provider's billing department to get the exact codes and amounts they would submit, and then trying to get insurance to price the hypothetical bill, or provide you with sufficient information to price it yourself. And obviously a bunch of the information we are assuming the patient has are unknowable until after the fact.

Part of the problem is insurance has a huge rule engine for deciding which line items are covered by not-allowable (meaning they get written off), plus insurance contract rates are only public for hospitals (so no info for providers that bill separate), and even then the data files don't always contain sufficient data to determine which of the multiple allowable rates for this procedure with this insurance at this facility, with these caveats actually applies).

AT protocol currently supports two different schemes for base identifiers based on w3c's DID system. The DID:PLC scheme is centralized, but not inherently tied to any one host. It is currently hosted and run by the Bluesky PBC, but they want to spin it off to help protect against themselves turning evil. This system lets users change their handle and move to a new personal data server seamlessly.

There is also DID:Web. This one has the downside that you need to continue to control the domain name in question indefinitely, and it can be argued that the domain name system is still a form of centralization. Like PLC users can theoretically change handles to another domain name with this scheme (but must contrinue to control the original domain name). Users can freely move to another personal data server.

AT Protocol can add new DID schemes in the future to avoid these downsides, with the caveat that users cannot change from DID type to a different one seamlessly, and adding new DID types may potentially require updates by multiple other parts of the ecosystem.

In my experience not many OTG devices actually used (mini-/micro-)AB ports, instead using just normal (mini-/micro-)B ports. The adapters generally just used a (mini-/micro-)B plug with the id pin wired like an OTG A plug. This does mean you can technically connect these adapters to non OTG products, which the spec writers wanted to avoid, but this simply meant the adapter didn't work.

I also have some peripheral devices with a captive micro-B cable (with ID pin configured like like micro-A) that were specifically intended to be used with OTG compatible phones.

For the document use case, most document formats do not embed the font, so in that case, you are fine. The license includes an explicit call out for embedding into a pdf: "Embedding of the Font Software is permitted for Portable Document Files (PDF), but only in such a way that the recipient cannot edit or extract the Font Software from the document".

It is not especially clear what that means, but my assumption would be that if you use subset embedding feature when creating the PDF you are fine, as that means even if somebody tries to extract the font, they would typically get a not terribly useful result, as unused glyphs, substitution tables, etc. would have been stripped.

And yes, as a general rule you cannot usually embed or otherwise distribute font files except as permitted by the font license.

On the other hand, at least in the US, you generally can distribute rasterized output of a font, because past court cases have clearly established that typefaces are not subject to copyright, but rather only the computer programs that procedurally generate typefaces from parameters is subject to copyright (e.g. font files). So, it is the vector data and stuff like the hinting mini-programs in the font file which are subject to copyright, not the resulting images it generates. Of course, you must still follow the license for the font software while using it to create a rasterized output.

See, I won't say magic can't work on television. It can work, but it does rely on a setting where the home audience can be reasonably sure the film crew is not in cahoots with the performer. This is uncommon, but in some limited scenarios like magic tricks on America's Got Talent, or say P&T's Fool Us there is little reason to cheat with video tricks, as those won't help with the judges/P&T at all, plus you risk having members of the studio audience call out the producers over such trickery.

Things like TV specials on the other hand, yeah not so much.

At runtime every value of any of these types are tagged in some some way. The struct based ones with an explicit tag member that is not visible at the language level. All the rest by way of the object's runtime type (v-pointer).

Which means the fact that some look at a language level like a traditional closed sum type, and others look more like a union type is pretty much just that, looks. Even the "ad hoc unions" are basically functioning as sum types here, just an ad hoc sum type whose type constructors are other types, and abusing the fact that classes or boxed structs all have a vptr that can be used as the discriminator.

This all compiles down to code that pattern matches on either the explicit tag member, or on the runtime type, and after the pattern match you basically have a normal type to work with. Hence why they are lumping it all together.

> Is this a type of beacon?

Pretty much. A similar approach of only unsolicited advertisement packets is used by a number of beacons. But that is not the only use case. A decent number of BTLE sensors out there also work exclusively by periodically sending out unsolicited advertisement frames with their data.

As long as you don't need to accept any incoming data, that is really easy to do, and allows completely shutting off the radio in between, so the radio may only be active for a few miliseconds once every few minutes. That helps keep power consumption very low, especially for battery powered devices.

If the primary sensor functions are low power, and support an interrupt signal, and you have a microprocessor with a low power timer interrupt (to allow waking up occasionally even if the sensor state has not changed), and ability to stop the clock to the rest while waiting, you can pretty easily get multiple years on a single disposable AAA or coin cell battery.

Shutters are complicated, as they are really are several different things.

For example, interior venetian shutters are closely related to blinds, but are not especially common in the US. Blinds with slats (venetian blinds) can perform a similar function, but can be raised to prevent any blocking of view, while interior venetian style shutters usually swing open and require additional wall-space. such shutters might win on maximum amount of light blocking (even vs wooden slat blinds) but that will vary by shutter design. Cost is certainly a major factor of them being uncommon (but far from unheard of, we even have multiple different names for them) in much of the US.

Roller shutters could be considered an exterior equivalent to roller blinds (or roller shades), although roller shutters are often designed with proper blackout capability, which most blinds and shades lack. I presume cost is one of the major reasons these are rare in the US.

Kick has a pretty bad reputation in the streamer community.

It first became notable when twitch banned certain gambling content, which kick allows. This gave it an initial reputation of being a site that allows content that Twitch does not.

the Wikipedia article mentions the site being founded with "a focus on looser moderation". When a site becomes known for lax moderation policies, it has a tendency to attract people whose content violates the rules of other platforms. While this might sometimes be good, a lot of the time it attracts people who want to promote bigotry or other hate.

As expected in the early days, the site did attract streamers that most competing services did not want to have. This has earned the site a bit of a stigma. There was at least one incident that would have resulted in the streamer getting suspended on literally any other game streaming service, and nothing happened over on Kick, and we know they knew about it, as their CEO was in the chat during the stream.

The site has tightened up its moderation a bit more vs the earlier days, but it has still yet to fully shake the stigma.

> If a human kept around a briefcase of NYT articles they didn't pay for and let you view them for a fee I think everybody would agree that's copyright infringement.

Sure. Slightly more interesting is if that same human with those same breifcases was taking money to answer questions and referenced those papers, but did not just provide the article or headlines, and might not even be paraphrasing the article at all. Is that okay?

To the extent it is merely paraphrasing articles, or outputting headlines that it just looked up, I agree that could well be infringement. If it more transformative processes those articles into something distinct, then it is not nearly as clear cut. The latter is arguably the intent of openAI, even if the current results might be closer top the former.

Recorded seperate samples for each test location, and then wrote visualization software that recombined those recorded traces.

Because there is no real reason for two different runs to be significantly different, (especially if the electronic switch shorts out the source ends of the wires between each test to discharge any capacitance that built up between the wires), the results should not be much different than if using an 80 channel scope.

The plan seems to actually be auto replace the Z values in the editor views with human readable values, which will automatically use the contributors preferred language.

This of course only works if all functions, and all parameters, etc have had labels submitted for your language.

They indicate wanting to cater to cultures that might not use a base 10 representation of numbers, so would presumably autotranforms numeric literals for people from those cultures.

They are worried about programming languages being englished based, but seem to think that similar autotranslating of keywords is a good enough approach, so that is why they NEED to support multiple languages, so that they might hypothetically support some language that supports base 60 math and keywords based on [insert language here].

Plenty of room for abuse here, as it would be really easy to edit functions being used for text generation of less popular languages to output offensive text, for things not tested by the test cases. And nobody except people who know that language will be able to tell for sure that this is not a legit contribution.

Then of course people will by trying to code sandbox and then container breaks, cryptominers, etc. I expect a giant game of whack-a-mole between the project and the admins.

On that note even ignoring the abuse, or people trying to utilize the service for free compute resources, I can see the costs of this service becoming substantial really quick. Just from things like legitimate contributions of test cases, and new language implementations, and running the test cases again all the different implementations.

Right, but the only punishment for failing to comply is reprimand and delay at the entrance while trying to verify citizenship. The latest publicly available CBP Inspector's Field manual is unequivocal that if the Inspector is convinced the entrant is an American citizen they cannot stop them from entering.

The law really exists as a way to avoid delays at entry as a US citizen having a valid US passport can be processed in much faster than one who does not, and it minimizes the risk of being stuck with an immigration agent that does not belive your claims of being an American citizen due to lacking convincing records and documents.

American Citizens are not the only ones with an unequivocal right to enter. American Indians born in Canada who have are at least 50% American Indian by blood "cannot be denied admission to the United States". They are required to prove to the inspector that they meet this criteria, but if they do, they don't need a passport or anything. (But they probably needed some documents to convince the inspector of their status as a 50%+ native born in Canada.)

The PostgreSQL's devs are fine with that.

Such use cases may not be quite as optimized as relational usecases, but they should be possible. If you are doing that then perhaps a different database would be nicer or faster for that scenario, but again not PostgreSQL's concern.

If the PostgreSQL devs were relational purists they would never have added special support for querying JSON.

An application may be better served with a properly normalized schema, or it might not. That is a choice for the application developers to make.

In practice competent developers should quickly realize if they went too nosql when a relational approach would provide benefits (Like if multiple "documents" need to reference consistent shared data, or if json query performance is not good enough) and normalize as needed to get those advantages.

So long as the application does not contain random sql queries scattered everywhere (and doesnt treat its database as a sort of API for external access) then database refactoring is not impossible. Indeed the difficulty is often overestimated. It is seldom fun work, and tends to be a bit of a slog, and require more extensive testing before pushing to prod, but that happens.