gshulegaard

I don't know, it's a pretty leap for me to consider AI being hard to distinguish from human contributions.

AI is predictive at a token level. I think the usefulness and power of this has been nothing short of astonishing; but this token prediction is fundamentally limiting. The difference between human _driven_ vs AI generated code is usually in design. Overly verbose and leaky abstractions, too many small abstractions that don't provide clear value, broad sweeping refactors when smaller more surgical changes would have met the immediate goals, etc. are the hallmarks of AI generated code in my experience. I don't think those will go away until there is another generational leap beyond just token prediction.

That said, I used human "driven" instead of human "written" somewhat intentionally. I think AI in even its current state will become a revolutionary productivity boosting developer aid (it already is to some degree). Not dissimilar to a other development tools like debuggers and linters, but with much broader usefulness and impact. If a human uses AI in creating a PR, is that something to worry about? If a contribution can pass review and related process checks; does it matter how much or how little AI was used in it's creation?

Personally, my answer is no. But there is a vast difference between a human using AI and an AI generated contribution being able to pass as human. I think there will be increasing degrees of the former, but the latter is improbable to impossible without another generational leap in AI research/technology (at least IMO).

---

As a side note, over usage of AI to generate code _is_ a problem I am currently wrangling with. Contributors who are over relying on vibecoding are creating material overhead in code review and maintenance in my current role. It's making maintenance, which was already a long tail cost generally, an acute pain.

IIRC `MERGE` has been part of SQL for a while, but Postgres opted against adding it for many years because it's syntax is inherently non-atomic within Postgres's MVCC model.

https://pganalyze.com/blog/5mins-postgres-15-merge-vs-insert...

This is somewhat a personal preference, but I would just use `INSERT ... ON CONFLICT` and design my data model around it as much as I can. If I absolutely need the more general features of `MERGE` and _can't_ design an alternative using `INSERT ... ON CONLFICT` then I would take a bit of extra time to ensure I handle `MERGE` edge cases (failures) gracefully.

I remember first moving to Philly and getting a SEPTA Key and thinking, "This is dumb, it's literally just a MasterCard. Why can't I use my credit card like NY?" Then a few years later they rolled out support for other bank cards and I immediately took my SEPTA Key out of my wallet.

When I lived in Portland you technically _could_ pay TTP, but I don't quite count it because Hop pass accrual meant if you used TriMet regularly you needed a Hop card anyway. Just out of curiosity I checked around and it looks like they extended that functionality to regular bank cards around two years ago [1]. Which is awesome as now the only reason to get a Hop pass is for people that qualify for reduced fares or are unbanked (which makes sense).

The multi-stage turnstiles at the RER stations… ugh.

Ah yes, had one of many, "I look like the tourist I am," moments navigating those visiting the Versailles.

[1] https://www.reddit.com/r/Portland/comments/1awweix/trimet_ex...

And yet I included a favorable international comparison as well.

I don't know what your frame of reference is, but BART is above average for US public transit payment systems.

I've lived in the San Francisco Bay Area CA, Portland OR, and Philadelphia PA over the last 10 years. All of those metros have comparable public transit payment systems with auto-loading special use cards and are at various stages of adopting support for tap to pay. Honestly, within the US I can only think of NYC as having a better payment system as they were first movers on tap-to-pay adoption and it's basically fully adopted.

Internationally I think there is a larger range of experiences. I don't travel enough to properly gauge it, but I was in Paris in the last year and I don't think public transit payment was better. Still had to acquire specialized fare cards and navigate different payment systems between RATP and RER. Honestly, SF Bay comes out slightly ahead of Paris if only because Clipper is unified between various transit options (BART, Bus, Ferry, CalTrain) IMO.

I also think asyncio missed the mark when it comes to it's API design. There are a lot of quirks and rough edges to it that, as someone who was using `gevent` heavily before, strike me as curious and even anti-productive.

but we know that reasoning is an emergent capability!

Do we though? There is widespread discussion and growing momentum of belief in this, but I have yet to see conclusive evidence of this. That is, in part, why the subject paper exists...it seeks to explore this question.

I think the author's bias is bleeding fairly heavily into his analysis and conclusions:

Whether AI reasoning is “real” reasoning or just a mirage can be an interesting question, but it is primarily a philosophical question. It depends on having a clear definition of what “real” reasoning is, exactly.

I think it's pretty obvious that the researchers are exploring whether or not LLMs exhibit evidence of _Deductive_ Reasoning [1]. The entire experiment design reflects this. Claiming that they haven't defined reasoning and therefore cannot conclude or hope to construct a viable experiment is...confusing.

The question of whether or not an LLM can take a set of base facts and compose them to solve a novel/previously unseen problem is interesting and what most people discussing emergent reasoning capabilities of "AI" are tacitly referring to (IMO). Much like you can be taught algebraic principles and use them to solve for "x" in equations you have never seen before, can an LLM do the same?

To which I find this experiment interesting enough. It presents a series of facts and then presents the LLM with tasks to see if it can use those facts in novel ways not included in the training data (something a human might reasonably deduce). To which their results and summary conclusions are relevant, interesting, and logically sound:

CoT is not a mechanism for genuine logical inference but rather a sophisticated form of structured pattern matching, fundamentally bounded by the data distribution seen during training. When pushed even slightly beyond this distribution, its performance degrades significantly, exposing the superficial nature of the “reasoning” it produces.

The ability of LLMs to produce “fluent nonsense”—plausible but logically flawed reasoning chains—can be more deceptive and damaging than an outright incorrect answer, as it projects a false aura of dependability.

That isn't to say LLMs aren't useful, just exploring it's boundaries. To use legal services as an example, using an LLM to summarize or search for relevant laws, cases, or legal precedent is something it would excel at. But don't ask an LLM to formulate a logical rebuttal to an opposing council's argument using those references.

Larger models and larger training corpuses will expand that domain and make it more difficult for individuals to discern this limit; but just because you can no longer see a limit doesn't mean there is none.

And to be clear, this doesn't diminish the value of LLMs. Even without true logical reasoning LLMs are quite powerful and useful tools.

[1] https://en.wikipedia.org/wiki/Logical_reasoning

I feel like this started/greatly accelerated when Guido stepped down as BDFL. Python at is on a path where the essence of what made it popular (readable, well designed, productive) is being crushed under the weight of it’s popularity. The language now feels bloated and needlessly complex in areas that were previously limited, but simple.

I recently chased down a bug where something was accidentally made a class variable because a type hint was left off it by accident and it clicked for me that Python is not the same language I loved at the start of my career.

The only point I put forth is that public fluoridation of water supplies doesn't infringe absolutely on an individual's right to informed consent to treatment since there is at least 1 method (moving) available that an individual can utilize to opt out. Others have pointed out that there may even be additional options available such as de-fluoridating yourself.

Did you have something on topic to contribute?

Or did you just want a soap box to voice your own opinions and I just happen to be collateral damage because you thought casting oblique aspersions about my qualifications would make you sound intelligent?

You could always move to a country which doesn't fluoridate their water supply.

But I am struggling to see how this has anything to do with a white paper highlighting and examining flaws in another white paper.

These days if you want a PostgreSQL based Data Warehouse both Citus and Timescale are extensions/PostgreSQL based databases I would consider before Redshift.

But even in the 9.4 days (~a decade ago) I was pushing Terabytes worth of analytics data daily through a manually managed Postgres cluster with a team of <=5 (so not that difficult). Since then there have been numerous improvements which make scaling beyond this level even easier (parallel query execution, better predicate push down by the query planner, and declarative partitioning to name a few). Throw something like Citus (extension) into the mix for easy access to clustering and (nearly) transparent table sharding and you can go quite far without reaching for specialized data storage solutions.

I just briefly reviewed the README docs, I believe the KlongPy is a custom language which transpiles to Python. The REPL block you are trying to interpret is the KlongPy REPL not a Python one.

Embedding KlongPy in a Python block would look more like this (also from the docs):

    from klongpy import KlongInterpreter
    import numpy as np

    data = np.array([1, 2, 3, 4, 5])
    klong = KlongInterpreter()
    # make the data NumPy array available to KlongPy code by passing it into the interpreter
    # we are creating a symbol in KlongPy called 'data' and assigning the external NumPy array value
    klong['data'] = data
    # define the average function in KlongPY
    klong('avg::{(+/x)%#x}')
    # call the average function with the external data and return the result.
    r = klong('avg(data)')
    print(r) # expected value: 3

Let me try again, from the first link I shared:

The __slots__ declaration allows us to explicitly declare data members, causes Python to reserve space for them in memory, and prevents the creation of __dict__ and __weakref__ attributes. It also prevents the creation of any variables that aren't declared in __slots__.

Emphasis:

prevents the creation of __dict__ and __weakref__ attributes. It also prevents the creation of any variables that aren't declared in __slots__.

In short, if you create a slotted object with __slots__ it sends you down a fairly orthogonal object lifecycle path which does not create or use __dict__ in anyway. This obviously has drawbacks/limitations like not being able to add new members to the object like a normal Python object.

From the second article:

However, if you have __slots__, the descriptor is cached (which contains an offset to directly access the PyObjectwithout doing dictionary lookup). In PyMember_GetOne, it uses the descriptor offset to jump directly where the pointer to the object is stored in memory. This will improve cache coherency slightly, as the pointers to objects are stored in 8 byte chunks right next to each other (I’m using a 64-bit version of Python 3.7.1). However, it’s still a PyObject pointer, which means that it could be stored anywhere in memory. Files: ceval.c, object.c, descrobject.c

Which I think addresses your concern about parent dict access...but I could also be misunderstanding your point.

Nope, __slots__ exist explicitly as an alternative to __dict__:

https://wiki.python.org/moin/UsingSlots

Whether or not the performance matters...well that's somewhat subjective since Python has a fairly high performance floor which makes performance concerns a bit of a, "Why are you doing it in Python?" question rather than a, "How do I do this faster in Python?" most of the time. That said it _is_ more memory efficient and faster on attribute lookup.

https://medium.com/@stephenjayakar/a-quick-dive-into-pythons...

Anecdotally, I have used Slotted Objects to buy performance headroom before to delay/postpone a component rewrite.

I was in the same boat, but the 30 minute fast charging now makes me think that this actually might work. Sleep with it on, wake up, pop it on the charger while you get ready, bam basically a full charge by the time you leave the house.

I don't wear an Apple watch at night (and I don't plan to upgrade to this one) but for the first time I think I could see how this might work for someone.

I have worked on teams that have both sharded and partitioned PostgreSQL ourselves (somewhat like Figma) (Postgres 9.4-ish time frame) as well as those that have utilized Citus. I am a strong proponent of Citus and point colleagues in that direction frequently, but depending on how long ago Figma was considering this path I will say that there were some very interesting limitations to Citus not that long ago.

For example, it was only 2 years ago that Citus allowed the joining of data in "local" tables and data retrieved from distributed tables (https://www.citusdata.com/updates/v11-0). In this major update as well, Citus enabled _any_ node to handle queries, previously all queries (whether or not it was modifying data) had to go through the "coordinator" node in your cluster. This could turn into a pretty significant bottleneck which had ramifications for your cluster administration and choices made about how to shape your data (what goes into local tables, reference tables, or distributed tables).

Again, huge fan of Citus, but it's not a magic bullet that makes it so you no longer have to think about scale when using Postgres. It makes it _much_ easier and adds some killer features that push complexity down the stack such that it is _almost_ completely abstracted from application logic. But you still have be cognizant of it, sometimes even altering your data model to accommodate.

Not everyone has a Costco membership or a Costco near them. There also doesn't seem to be any indication that there is a pre-arranged pricing arrangement for Amazon like Costco.

Amazon is simply letting Hyundai dealerships list car inventory on Amazon, Amazon isn't selling the cars.

While I agree with what you are saying in principle, I do want to point out that there is a massive difference between anecdotal evidence and _research_. In a purely academic sense, it is not an unreasonable statement to make that there is no evidence. In contrast, in the opioid case there existed scientific evidence of the highly addictive nature of the drugs that was more than just suppressed, they were outright _lied_ about by the pharmaceutical company behind the drug.

Purdue Pharma created false advertising documents to provide doctors and patients illustrating that time-released OxyContin was less addictive than other immediate release alternatives. Furthermore, they sought out doctors who were more likely to prescribe opioids and encouraged them to prescribe OxyContin because it was safer. They did this because OxyContin quickly became a cash cow for the company. (https://oversight.house.gov/release/comer-purdue-pharma-and-...)

A degree of malfeasance in the same realm as Big Tobacco's denials of the risks and addictiveness of smoking:

https://www.cbsnews.com/news/big-tobacco-kept-cancer-risk-in... https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2879177/

Although, perhaps could be considered worse since it occurred more recently in a theoretically more highly regulated market than mid 1900's tobacco.

Thanks for taking the time to explain the nuanced implementation difference.

Both http2_max_concurrent_streams and keepalive_requests (the configuration parameters discussed in this article) are configuration parameters available in open source nginx:

http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_...

http://nginx.org/en/docs/http/ngx_http_core_module.html#keep...

So are limit_conn and limit_req:

https://nginx.org/en/docs/http/ngx_http_limit_conn_module.ht...

https://nginx.org/en/docs/http/ngx_http_limit_req_module.htm...

So it pertains to both NGINX and NGINX+.

I am not sure I understand how stream limit configuration between two L4/L7 load balancers is meaningfully different. In my mind, either the configuration of stream limits is a vulnerability for all L4/L7 load balancers that offer that configuration or it's not for all of them.

If one doesn't _offer_ configuration of stream limits and therefore is not susceptible to user misconfiguration, then I would get the distinction. But as I understand it both HAProxy and NGINX have the same configuration options which _could_ be vulnerable if configured poorly by the user. One is just putting a lot more positive spin on it.

There is a difference between an application being innately vulnerable and a user configuration exposing a vulnerability.

Interestingly enough, HAProxy seems to have the same mitigation:

Until HAProxy dips below the configured stream limit again, new stream creation remains pending—regular timeouts eventually apply and the stream is cut if the situation does not resolve itself. This can occur during an attack.

https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-...

That is, if I read it correctly, default configuration is safe and you can use configuration of stream limits to ensure you are not vulnerable, but they are saying HAProxy is not vulnerable...at least in the title. Later on they soften the language:

HAProxy remains resistant to HTTP/2 Rapid Reset

If you followed the source that is cited/linked in the quote you copied you would have found:

The Messi Effect is real! Subscribers to #MLSSeasonPass on @AppleTV have more than doubled since Messi joined @InterMiamiCF. Also, Spanish language viewership on #MLSSeasonPass on @AppleTV has surpassed over 50% for Messi matches and continues to rise. How exciting for a truly global fan base!

https://twitter.com/Jorge__Mas/status/1689758782828556288

I mean, it wasn't too long ago we had auto pilot software from a major aerospace engineering company that would literally pitch planes into nosedives when only one of two redundant angle-of-attack sensors misbehaved/failed.

Also there seem to be quite a few train derailments as of late.

Oh and what about that apartment building that just...collapsed in Ohio?

Seems like there have been quite a few cases of safety regulatory failure in recent memory.

Well that's precisely what we were doing until 2018 when lobbyists and the Trump Administration carved out exceptions for banks with less than (or equal to) $250 Billion in assets (see link above). So a more pertinent question from my perspective is: "Who's brilliant idea was this anyway? /s"

But if "the answer" you are referring to is to prevent consolidation in banking, then I think it's not quite as cut-and-dry. Regulation, especially risk-management regulations, can act as barriers to entry and create an environment that favors larger/established institutions leading to market consolidation. As an over simplification by a layman, it could look something like:

    - Higher regulation constrains profitability and raises fixed costs of running a bank (compliance burden).
    - This means that the amount of assets under control by a bank has to be higher in order for the bank to be profitable.
    - This higher floor reduces the likelihood new banks start (since the asset requirements to be profitable are higher).
    - Existing banks, in an effort to increase profits, acquire and merge with other banks.

I am definitely _not_ suggesting small banks should be exempted from Dodd-Frank like they were. I actually found the 2018 deregulation disturbing and disappointing. I am only trying to illustrate that even if 2018 hadn't happened, I don't know for sure if there would be more competition in the banking industry. (Only that the banks we do have would be less risky)

I think this comment is missing a key bit of context in that regionals/smaller banks were exempted from some of the regulations of Dodd-Frank.

https://www.npr.org/sections/thetwo-way/2018/05/22/613390275...

So it's not that we assume bigger banks can better manage risk, we are simply, currently regulating them to manage risk better.

I wouldn't set random_page_cost lower than seq_page_cost. It can cause the query planner to do wacky things (I learned the hard way). The documentation mentions it, but not as strongly as I think is warranted given how erratic my PostgreSQL cluster started behaving after I made that configuration change.

Although the system will let you set random_page_cost to less than seq_page_cost, it is not physically sensible to do so. However, setting them equal makes sense if the database is entirely cached in RAM, since in that case there is no penalty for touching pages out of sequence. Also, in a heavily-cached database you should lower both values relative to the CPU parameters, since the cost of fetching a page already in RAM is much smaller than it would normally be.

https://www.postgresql.org/docs/current/runtime-config-query...

Curious though, lowering both values is something I haven't done before but now I am curious about.

I think I would rephrase this question as why would I stop using emacs for VS code and intellij? Seriously, there is no feature they have that my emacs config doesn't (AFAICT after using Intellij and VS code each for 4+ years). But I have the ability to work with emacs without ever touching my mouse. You may consider that only being "slightly" faster, but every time I use VS code, _feel_ slow because I know how fast I would have been in emacs.

Combine this with my tiling window manager and I pretty much only have to use my mouse to interact with web browsers. That's the killer feature that makes VS Code and Intellij _feel_ inferior to me.

Now I wouldn't go so far as to say that VSCode and Intellij are _actually_ inferior to Emacs. I think both are great in their own right, but after years of familiarity I have a fluency with Emacs (because of the keyboard oriented interface) that I could never have with them.

To be fair, for someone without emacs fluency I would probably steer them towards VSCode and Intellij as they are definitely more approachable. In fact, I have done exactly that for several of my friends and colleagues.

So interestingly enough, the Pangolin is the first laptop model I am aware of from System76 that isn't an outright Clevo chassis (via Sager). I don't know all the facts but I did find this interesting reddit comment:

https://www.reddit.com/r/System76/comments/10a3lqj/comment/j...

Which suggests there are pretty major changes to how they have previously done laptops:

1) The manufacturer is Emdoor(?) instead of Clevo. (I have never personally heard of Emdoor)

2) Final assembly is done in-house @ System76 instead of via Sager. That is assembly for Pangolin is done in Denver at the same place the Theelios desktops and Launch keyboards are made.

While not necessarily all in-house yet, both of these changes are a pretty massive difference so as a former owner of several System76 laptops, I am curious how much better the Pangolin is.

Edit: So after doing some googling, it seems like Emdoor is a Chinese manufacturer out of Shenzen (https://www.emdoordigi.com/about.html?category_id=0). Personally, not sure moving from a Taiwanese manufacturer to a Chinese one is actually a good thing...but still curious none-the-less.