breatheoften

Interesting ... plenty of opportunity then potentially for the 100 samples to have prediction similarity to the set of published discoveries (for expected or unknown reasons)?

I suppose it will take a few more years of repetition for the challenge to confirm that the problem has been been solved -- but I wonder if a new version of the contest is going to be needed as well? Maybe the model accuracy is now high enough to invert the contest to a form where models generate predictions for randomly selected unknown samples -- and experimental teams are then expected to make observations for those particular sequences over the next two years as part of their otherwise research agenda selected experimental workload?

Only 100 new structures each test cycle? That seems a very small test set size ...

Is it really possible to select 100 new structures which together are likely to represent a meaningful increase in the sample generalization versus the prior years test set ...?

That's quite interesting ... I believe the test set size is not constant year to year but rather a function of how many new structures have been experimentally discovered since the last contest?

Does seem like the contest structure could include quite a bit of risk for hiding the effect of overfitting ... I wonder if there is anything inherent about the problem that reduces that risk ...?

Anyone care to muse about appropriate investment strategies based on the not previously feasible research approaches that might now be possible?

Should we expect to see faster progress in large well capitalized bioscience companies -- or a sudden increase in the viability of smaller biotech and/or biotech startups ...? Are we gonna see top talent fleeing the old biotech companies to start their own ventures with a new belief that the potential for huge reward might suddenly seem achievable?

What kind of companies do we think will be the first that are able to translate this new knowledge into profits?

Why would latency suck? 64-cores are already only beneficial for algorithms which are parallelizable -- with the most common class of parallelizable algorithm being data parallelizable ... So -- shouldnt the hardware and os be able to present the programmer illusion of uniform memory and just automatically arrange for the processing to happen on the compute resources closest to the RAM / move the memory closer to the appropriate compute resource as required?

I hope that hypervisor eventually "becomes the os" -- such that macOS or linux or whatever "collected set of software that needs to think it has an ownership relationship to hardware state" can all run on top of essentially the same hypervisor provided hardware abstractions ...

I think the argument they were trying to get to but totally failed to make is possibly along these lines

huge memory bandwidth relative to ram size + os level memory compression => massive reduction in memory pressure for many many many workloads.

macos has supported memory compression for awhile now -- i would hypothesize that M1 may have massively improved that subsystem in ways that actually do translate into needing less memory on average for a lot of common real-world workloads that amount to "human timescale multitasking" between large working sets -- eg i click this app and it has a huge working set and then click into another that has a large working set and then click back -- with those clicks that represent application context switches occurring very very rarely in machine time scale.

If memory compression subsystem can swap working sets into and out of compressed memory space insanely quickly with low power usage then the os might've gotten very aggressive about using that feature to put not recently accessed memory into compressed memory space.

I'd love it if typescript could one day grow a mechanism to allow it to rewrite closure definitions to contain the inferred type declarations -- some kind of keyword to indicate "this return type will be re-inferred by compiler based on the call sites within local scope" and have it integrate with ide "rewrite on file save" infrastructure.

So you get minimal keyboard typing when passing around inline closures -- don't have to write the types yourself or maintain them as the code changes -- and any changes to the inferred return types would be visible in source control with diffs that provide quite rich information about changes that might have done something unexpected or propagated further than realized

I'd be checking for bugs in the js -- particularly as might be triggered from a bot environment that one or more of your customers might use to test their site or observe their sites latency response ...

puppeteer with setRequestInterception configured to block responses in the right way maybe https://github.com/puppeteer/puppeteer/blob/v5.5.0/docs/api.....

I can imagine nightmares along those lines that could persuade some normally functioning js client logic that works normally when in a normal network environment to continually reissue failed requests when browser requests/responses are blocked in just the wrong way -- that could cause the same client side ip to appear in logs over and over again.

And then ip variability could be the customer spinning up browser bots in various regions around the world in order to measure their sites region specific latency response.

Just offering up an alt theory -- as I'm with some of the others -- not sure the graphs shown immediately scream dos to me.

rubocop config in this scenario is objectively wrong in my opinion -- a better config would be to flag "foo if bar?" as linter violation and just never use it. (I would also forbid "unless" statements -- why the hell does anyone need unless??)

The only reasoning I need to support my opinion -- Ruby debuggers are not good enough to support mid line breakpoints -- so if you want to break only when the condition is true -- which is a very common thing if you are maintaining or debugging code you didn't write yourself -- you literally can't without changing the code or using a conditional breakpoint and duplicating the conditional inside the breakpoint definition -- this is very annoying when tracing unfamiliar code and trying to figure out what invariants are relevant to a given scenario (or missing).

In my opinion - linters need an actual concept of a user that they are trying to help -- and ideally that concept should lead to objective opinions. Linters like rubocop that are just piles of functionality tend to be breeding grounds for time wasting arguments between insufficiently experienced developers over opinions that aren't supportable from any usefully pragmatic basis.

Apple making some of its components bypass application level firewall might need to occur given the reality that a modern os is a decentralized system -- but I really think the set of such code with this functionality should be minimized to the absolute smallest possible surface area -- and this behavior should be confined to a tiny set (or even a single) of system components ... "low latency clock coordinator component" or whatever the true architectural reason for the system to require unfettered network access is ...

It seems to me like ultimately the only use cases that should require bypassing network controls will relate to scenarios where there are architectural constraints imposed by the need to minimize latency - and minimizing latency needs to be possible ... so Whatever needs to happen at the architecture level to ensure minimal latency is going to need to happen -- but hopefully only those things ... -- and hopefully only in ways that are visible and decoupled from content-ful network transactions ...

Typescript for python?

I'm not sure what specific technologies "blockchain databases" is limited to -- but one use case that has been bandying around me head ...

I think there could be a very powerful set of regulatory technologies created on top of blockchain style databases when used in conjunction with legally binding agreements intended to limit access to reads of the data.

Imagine a data lake for "enforcing" audit-ability of reads --

1. you may "store" some data in the lake -- say for example P2 2. if you "store" data in the lake you agree that you will not store that data anywhere else

"store" above would in actual implementation be something like storing a key for decrypting the data -- which could be stored wherever in an encrypted form and the agreement would mean "i'm not storing the key anywhere and i'm not storing the decrypting contents in any form other than as encrypted by the key".

You would leverage blockchain to ensure that all reads of the data are observable.

Obviously you can't "enforce" that the data being protected is not stored in other places or in other forms -- however the agreement "i will not store anywhere else" can be given legal or regulatory force to provide a way to punish violators.

The goal tho is to build a platform for explicitly acknowledging and communicating to both external auditors and the developers that "i'm not supposed to store this in other places". That's a technology problem which a lot of good faith implementors need help with solving ...

So is the normal usage path to start using osh for interactive use and then use osh in a bash compatible mode to write scripts that are less buggy but can still be run on bash?

Or is it more common to write scripts that tend to then require the osh runtime exist in whatever context they are deployed to?

Are there any transpile to bash languages?

I like the idea of a language that allows for a better experience in writing shell scripts -- and produces shell scripts with fewer bugs on the output side.

But i wonder if a transpile approach wouldn't be better in the long run

If the language defines a way for you to ask the program for the computation graph in order to differentiate -- couldn't you add meta programming functions on top of that computation graph?

Seems to me like there's at least an argument that it should be possible grow diff programming into a general purpose meta programming system rather than use general purpose meta programming as implementation mechanism for differentiable programming ...

Buttons on both sides also completely breaks the ability to use the volume rocker buttons as a camera shutter -- 'oh let me quickly grab my phone and take a pictu--- nope, I hit the sleep wake button, sorry'

I hate that iphone 6 and onward design decision ... (design-wise pretty much everything after iphone 6 has been a regression imo, although this one looks the best that any phone has looked in a long time -- aside from the notch)

> Microsoft has plenty of paying customers to continue supporting Windows as-is, some for decades

I have to respond to this thought because -- I don't think its true.

Aside from government and military, which of those paying customers truly have revenue streams so guaranteed that those entities cannot be replaced or outcompeted over the course of decades by somebody approaching the problem with fresh eyes -- or even just some internal division at the same company approaching the problem with fresh eyes and building something _better_ because it was allowed to change as opposed to something very stable because it is _not_ allowed to change?

For government -- do we really want/need our government throwing money away because they are more or less not allowed to development new solutions to old problems?

For military -- ... yeah well ... I don't know what to think about military ... Military is not a sector that has any measurable goals aside from self-perpetuating its budget so its hard to argue against boondoggle maintenance projects as having some capacity for objective success with regard to that goal ... But -- perhaps there is a future where the system could reasonably decide that the wisest course is to _not_ spend billions of dollars keeping 1980s era visicalc programs running unmodified so that they can properly manage the floppy disk supply chain for nuclear missile silos ...

I don't know the specific implementation mechanism -- just guesses.

But that doesn't mean my observation of the behavior of the bug is unlikely.

And also -- there is not a hard requirement that only one editor exists -- the same user could use multiple devices at the same time. Consider that and you might find your assumptions to be invalid.

I could be wrong but i'm relatively sure that I reach message states that do not directly correspond to anything i typed into the editor -- which i wouldn't expect if the edited state was always sent in full rather than as a delta on a previous message state.

I suppose it's possible that the corruption happens on the client side tho --

1. initiate edit action and get editable view of snapshot of text

2. server acks some previous edit request causing some client state related to the message to update and promote a previous edit in some way

3. hit save after finishing editing -- and some delta operation on the client side updates a different message state than the one i initiated edit action from ...

I frequently send - edit send - edit the same message in an effort to reduce the number of typos.

Recently i've realized that this actually introduces more typos -- where a large number of phrases are duplicated or corrected typos reapplied.

There's something wrong with slacks operational transform or CRDT implementation or whatever they use to get edited messages to converge

I don't care what the icon is -- just ensure it has a label that says "Save" or something similar ...

I hate icons without text!

"Here's an image, guess what is supposed to happen when you click it, also i will give you no info on hover over -- you must push me and then try to guess what i did!" (btw if there's a bug or a configuration state in the app that you or i am unaware of -- you might've pushed me at the wrong time and i might've let you do that)

Lose its competitive advantage, slowly consolidate remaining assets into private hands with borderless migration capacity, elect a government composed entirely of conman, and five to ten years from now, begin losing every violent international confrontation that it tries to start?

I have some tree data represented in jsonb fields -- is it possible to build a materialized view on top of recursive traversal of a jsonb data structure -- to extract a view like this ...?

owner_id, element_path, element_id

where element_path would be something like an LTree -- to allow easily querying over the set of traversals defined in the jsonb?

Is it a reasonable way to represent the tree in convenient way for queryomg purposes while also allowing data updates to stay simple?

Does a data trust require you to prevent "entities other than the trust" from storing data?

Is there a way to do that ?

Fascinating!

The mere existence of such an api would be an interesting source of problems when used accidentally/via buggy code ...

I wonder the degree to which this functionality would end up becoming relied on as a "in worst case hard kill things to recover" behavior that folks utilize for bad engineering reasons as opposed to good ones ...

1. Bringing up the print dialogue is a slow process so its annoying when you hit cmd-p on accident 2. Print operation is done very rarely and not frequently invoked in the middle of a keyboard-centric workflow -- how often would it not be more or less equivalent keyboard interruption to use the Print Menubar Action vs cmd-p? 3. It would be nice to steal the shortcut from all apps and remap it to something useful ...

> Command-P: Print the current document

Can we please remove this one ...

Yes but there is no reason a language ecosystem can't assumes that this functionality is present, implemented in canonical form, and that it is a language use error not to enable.

If the language designers assume the capability exists and will be used -- they can specifically evolve the language based on this assumption. All thats needed is a super high quality, compiler-provided implementation of the functionality -- and to set the expectation -- "sorry you have to wire this functionality up -- otherwise your code is going to be more likely to break if you edit the source files over time while also upgrading your compiler over time."

I'm benoaning the fact that no languages I'm aware of have advertised such a position as part of their evolution plan ...