It took me quite some time to realize what an utterly presumptuous product name Claude Code actually is, but only because Shannon is rarely mentioned with his first name. It's golden calf levels of hubris, even more so if you consider how incapable it was on release. It's like renaming calc.exe Einstein. Incredibly poor taste, but entirely in line with AI tech bro mentality.
That linkage never occurred to me, or, I suspect, them. Claude use to be a reasonably common name. I have an uncle Claude. Why do you believe they named it after Shannon in particular?
There are some good designs which prevent them from getting dirty. For example, Mercedes and VW put them in the rear badge and they're only exposed when needed.
This is the fault/price of backwards compatibility. Most users of SQLite should just fire off a few pragmas on each connection:
PRAGMA journal_mode = WAL
PRAGMA foreign_keys = ON
# Something non-null
PRAGMA busy_timeout = 1000
# This is fine for most applications, but see the manual
PRAGMA synchronous = NORMAL
# If you use it as a file format
PRAGMA trusted_schema = OFF
You might need additional options, depending on the binding. E.g. Python applications should not use the defaults of the sqlite3 module, which are simply wrong (with no alternative except out-of-stdlib bindings pre-3.12): https://docs.python.org/3/library/sqlite3.html#transaction-c...
While it has bad ergonomics, you can also use CHECK constraints. For example, using sqlite's built in date support, it's possible but awkward:
CHECK (
date(my_date_col) IS NOT NULL
AND my_date_col = date(my_date_col)
)
The IS NOT NULL is needed because date returns NULL for invalid dates; the other check because it also accepts Julian days (date('2026') is sometime during year 4707 BC).
It literally is? Changing the defaults shown in the PRAGMAs above would break backwards compatibility. SQLite is strictly semantically versioned and does not break backwards compatibility.
Their complaint was SQLite's type system was poor. You said this was the price of compatibility. And the documentation of your recommended pragmas said nothing of types. They seemed unrelated helpful advice seemingly.
New types would break forward compatibility in SQLite's terms. 3.7.0 added WAL mode was their example of a forward compatibility break.[1] 3.y.0 could add better type system mode.
It’s a fair assumption that most of these things are trickle-down effects of CMS/R155 and CRA combined with very high risk aversion on the company side. The less you expose, the lower the risk.
These things have started to look a lot like big iron CPUs from the late 90s with unusually thicc PCBs, being crammed full of (then cache) memory chips around a huge chip or two in the center, periphery lined with odd high-speed connectors and power delivery etc
> My real problem with the evolution of Python is that initially, the language and the community was positioned as anti-Java, anti-big-OOP-like-C++, and then it changed into the thing that it was against, but in a roundabout and suboptimal way. To me, the initial vibe of Python was, "write a 100-line script, don't worry about explicitly documenting types, don't worry about grand architecture, don't worry about creating custom classes, don't worry about encapsulation and public/private". I've been with Python since year 2007 in the 2.x days, and Java since 2002.
It really wasn't that anti-Java. Late 90s / early 2000s had a huge branch that was very dedicated to Java-style OOP. E.g. anything to do with Zope, and GvR himself worked on that at the time. Zope even has had its own ABC / interface system, specifically modeled after Java interfaces. stdlib logging is a reimplementation of log4j in Python and so on.
For a bunch of software categories there isn't really much point to support Windows at all these days. We've had "developed for unix, ported to Windows" software for a long time and it often doesn't work that well, because the agreement even for fairly basic stuff is not that large between the two.
1: My point isn't "developer on unix, ported to Windows", it's "developed on linux, maybe works elsewhere".
2: You could easily compile Samba yourself for FreeBSD in the past, last time I tried a new version it broke in what I remember being due to linux-isms (yes there is ports, but being reliant on older versions if ports maintainers can't keep up isn't a good thing).
3: The only "fairly basic" stuff that's hugely different is mostly the absence/reliance on shell-scripts (when building), but that has little to do with the actual code function (Personally I often used Node scripts in those scenarios, Python scripts would probably be an improvement since there's no reason it couldn't be everywhere).
I used to use Tremor to decode Ogg audio (no UI needs, just binary data in, arrays of primitive values in audio buffers out), early versions were easy to compile under Windows but building later versions were buried in shell scripts generating headers,etc for no real good reason (maybe to help port when working on a Linux workstation to other embedded devices but made the code less easily compilable by default), the core functionality only really needed a C compiler as early versions showed.
I can agree that something with advanced UI's like Blender (that relies on GL/3d rendering for UI) might not be easily portable, but when algortihm libraries often requires heavy reworking it's not a good thing (Here I think Github has helped since people has had an easier time to contribute, it's a sad thing that people are moving away due to the AI-crap).
In the end, it's not about _actual_ differences but more of a superiority complex of Linux users that is the main roadblock.
How many times have we been told that we're entitled freeloaders for expecting Linux compatibility work from others? Insulted by people who use dominant platforms that get all the commercial support while we get literally nothing? Reduced to reverse engineering stuff with no documentation and zero help?
Pretty wild to watch this unfold. Now that Linux is finally coming out ahead, as it should, because people are finally writing software for it... Suddenly we're the bullies.
This isn't a new thing, like I mentioned in another comment it goes back to freshmeat.net days ("oh, cool a tool to manipulate fileformat-x", "oh ok too full of gcc-isms, linux-only headers to run on either windows or even bsd").
I worked in gamedev, consoles, etc. Linux support was often discussed but the whole mess of different libraries on various distros vs static library linkage legality, evolving audio api's,etc was real blockers (Valve just defaulting on Wine and Win32 binaries for steamdecks could be discussed at length).
Honestly, could even be posited that the rise of the Web as a delivery platform, Java and Node,etc is in large part DUE to the fragmented story of much of C/C++ code platform-tiedness, Linux just happened to move ahead due to it's momentum as the "free" option (quotation marks due to Android).
> oh ok too full of gcc-isms, linux-only headers to run on either windows or even bsd
You have the source code and it's literally free software. What else do you need?
It's honestly pretty incredible to hear complaints like "it didn't compile on my preferred platform unchanged".
> the whole mess of different libraries on various distros
All the various Berkeley Software Distributions out there don't have different systems and libraries of their own?
This is a user space problem anyway. Linux kernel is actually better here. Linux actually lets you bypass system libraries and talk to the kernel directly. You can write Linux applications in freestanding C and they will work. BSDs will eventually break ABI and your program if you do that.
> static library linkage legality
Nothing illegal about it. Just gotta follow the terms of the GPL. Whether you're willing to do it is a completely separate matter.
> Valve just defaulting on Wine and Win32 binaries for steamdecks could be discussed at length
Don't think there's any discussion to be had here. It's just the pragmatic choice that buys us access to vast amounts of existing software that will never be ported. Linux kernel is even gaining NT functionality now just to support this. Nothing wrong with it.
You can totally get Linux versions of games in the Steam Deck, it's just that they're often second class ports, outdated and generally forgotten by all including the developers. There is no reason whatsoever to sit around waiting for things that will never come.
The decent cross-compatibility in the early 00s was a result of the multipolarity of the era.
In the late 90s-early 00s we had SystemV, Linux, BSD, macOS and the market begged for standards like POSIX and to an extent CDE and many other proposed ones. As the largest player, Linux always had an attitude.
Now, after winning the Server, embracing, extending and extinguishing the Workstation/Desktop(WSL, Valve), and with a foothold in mobile(Android) Linux is the de-facto standard.
The BSDs have declared POSIX dead and gone their own way while supporting Linux(SystemD, Wayland) APIs even if they are more half-baked than POSIX in order to benefit from what is now virtually a Linux ecosystem.
I don't like this any more than you but it is what it is.
Exactly, the amount of patches needed in many FreeBSD or other BSD ports just to appease the Linux-centricity is bonkers. And many times the changes aren't even that grave.
There's portability between systems, which as you note, has ever-diminishing returns.
Then there's portability between compilers, which, as the article notes, glibc is also completely hostile to (except for anointed compilers) for no good reason whatsoever.
in Asia, and over here, Windows is the de facto standard while Linux is actually a poor option. Almost all of the infrastructure is written for Windows, so the second you switch to Linux, you're fighting an uphill battle just to do basic tasks. Seeing this makes you realize that our worldview is entirely shaped by the ecosystem we live in
reply