It makes sense to target a higher operating temperature, like 375K. At some point, the energy budget would reach an equilibrium. The Earth constantly absorbs solar energy and also dissipates the heat only by radiative cooling. But the equilibrium temperature of the Earth is still kind of cool.
I guess the trick lies in the operating temperature and the geometry of the satellites.
The label 'open source' has become a reputation reaping and marketing vehicle rather than an informative term since the Hugging Face benchmark race started. With the weights only, we cannot actually audit that if a model is a) contaminated by benchmarks, b) built with deliberate biases, or c) trained on copyrighted/privacy data, let alone allowing other vendors to replicate the results. Anyways, people still love free stuff.
Rather than API/ABI stability, I think the problem is the lack of coherence and too many fragile dependencies. Like, why should a component as essential as Systemd have to depend on a non-essential service called d-bus? Which in turn depends on an XML parser lib named libexpat. Just d-bus and libexpat combined takes a few megabytes. Last time I checked, the entire NT kernel, and probably the Linux kernel image as well, has no more than single-digit MBs in size. And by the way, Systemd itself doesn’t use XML for configurations. It has an INI style configuration format.
The difference is that you can customize/debug it or not. You might say that a .EXE can be modified too. But I don't think that's the conventional definition of open source.
I understand that these days, businesses and hobbyists just want to use free LLMs without paying subscriptions for economic motives, that is, either saving money or making money. They don't really care whether the source is truly available or not. They are just end users of a product, not open-source developers by any means.
Downstream assembly factories attract component manufacturers because of lower transport costs and shorter delivery times, which can lead to network effects. (Remember why Intel wanted to build more foundries in China a few years ago?) That's the success formula of Shenzhen, for example.
Maybe the README should mention whether reflection (the part that would disable dead-code elimnation) is used? That was a pain point for me when I had to investigate a binary bloat issue due to reflect.
Homes are not a homogeneous commodity. New homes cannot be perfect substitutes due to locations, amenities, access to jobs (commute time), etc. Also, government spending on infrastructure will be capitalized into the neighborhood's land (location) value. You cannot 'undo' this capitalization simply by building more homes.
C# is fine. But last I checked, the AOT compilation generates a bunch of .dll files, which are not suitable for a CLI program like Go's zero dependencies binary.
In my honest opinion, it's not a good idea to mix two programming languages into the same monolithic codebase side by side. It would be less problematic if used for different purposes or layers, like frontend and backend. But we know it still creates unpleasant friction when you have to work on both sides on your own. Otherwise, it creates technical AND communication friction if the C devs and Rust devs work separately. As someone who works with embedded systems at times, I can imagine the pain that you have to set up two toolchains (with vastly different build infra beasts like GNU Make and Cargo) and the prolonged build time of CI and edit-compile-run debugging cycles given the notorious slow compile time of the Rust/LLVM compiler.
CREATE MACRO foo(bar, baz) AS TABLE
WITH
base AS (
FROM query_table(bar) t
),
refined AS (
FROM base
JOIN query_table(baz) u ON base.id = u.id
)
SELECT * FROM refined;
I want to test many user-defined combinations of (bar, baz). How can I pass a macro instance to query_table like
FROM (
(FROM foo(mybar1(some_arg1, some_arg2), mybaz101(500)))
UNION ALL
(FROM foo(mybar2(some_arg3, some_arg4), mybaz201(300)))
UNION ALL
...
)
SELECT *;
Your second example using the 'query_macro' looks like something I was looking for. But it doesn't seem to be of general use that supports an arbitrary number of arguments.
DuckDB macro doesn't support instantiating a table macro using the `query_table` function. So, it's not possible to expand a table macro like `foo(bar(baz()))`, making its use limited.
Open source has pragmatic merits and I love the culture. But I don't like associating it with a moral high ground because it doesn't charge you money. By this standard, we should also ask Intel/AMD to open-source their CPUs, video game studios to open-source their code and artifacts, and Google/Amazon for their search engine and infrastructure. Not all business sectors can afford to sustain with the Open Source model.
This baffles me a lot as TikTok and RedNote have very distinct market niches except for their Chinese origin. I assume if someone were interested in a flavor of social media like RedNote they would have been on it already.
Is there a really strong market demand for whatever social platform as long as it's owned by a Chinese company?
No. Sustaining a business with a margin doesn't necessarily mean that maximizing the margin has to be the ultimate goal. A company can look to maximize market share, revenue, or other ambitions.
It depends. We can say that China’s industrial policies are a kind of protectionism as well in that they are willing to pay for extra cost for domestic “national red supply chain independence” rather than relying on the “comparatively advantageous” western vendors. And they did get excellent results. Note that industrial independence is exactly the opposite of free trade and that has been a long sought national goal by China.
Regarding tariffs on China exports, the relatively fortunate position for the US is that the biggest components in consumer inflation index such as food, housing and energy are all either largely domestic produced or not dominated by China, which gives more room for the US to react. But the tariff could still harm the gross margin of the international enterprises and even SMBs, who are facing the immediate pressure of adjustment during the trade war.
The popularity of a programming language is not always about what the language offers. I would say a comprehensive, well-documented, mature set of standard libraries for its target audience is far more important (notable examples like R, Python, and Go). Last time I checked, Ada doesn’t even have a de facto, high quality TLS/crypto library, let alone various essential protocol/format codecs, yet the core team (AdaCore I assume) puts a lot of resources into offering a few sophisticated flagship IDEs that potential hobbyists would never use (they already have vim, emacs or vscode). I understand that as a business they have to sell something for revenue and they cannot sell standard libraries. So, that’s probably a dilemma that we cannot have the nice things for Ada to take off.
I agree that export restrictions would potentially help the advantage in the AI race to some extent, however, the primary factor that leads to the tech advancement and China's dominance in manufacturing is not where the US sells to, but where the US buys from. I would say the best resource to advance an industry is not IP thefting or government subsidies but the tech leaders' purchase orders (and customers' specifications and requirements learned from those orders). For instance, AAPL has contributed to the progress of the component supply chain and then the emergence of a bunch of China phone companies. Later TSLA did the same for the Lithium-ion batteries companies and the EV industry in China.
I have no philosophy issue with systemd. The biggest show-stopper (on embedded Linux) for me is its install size. We have edge devices with only 64M RAM and 128M NAND flash. For an OTA update (via Bluetooth sometimes) only ~20M in total, adding ~5M systemd plus its dependencies doesn't make sense. 5MiB is roughly equivalent to the entire Linux kernel image on those devices.
Among the components of systemd, the part that has the lowest added value for our use is dbus. It's designed primarily for desktops and useless for most of our systems, but unfortunately, it is also a hard requirement for systemd.
As far as I know, they do. I think the bigger problem of the US manufacturing industry is that the most talented and motivated people have gravitated towards Wall Street and the "ads" companies. They not only pay significantly higher (due to cost/revenue structure) but also have a comfy working environment compared to factories.
The lack of these design elements in a solo project does not define crappy code. More often, it's due to a codebase being modified by multiple contributors, each wanting to get their work done quickly without paying attention to the overall context or considering others' work.
Looks neat and convincing. But I think the goal (and effort) to make it into the C++ standard would hinder the momentum of adoption. I suspect it would have to go through a lot of politics and bikesheding before making any real-world impact.
Imagine that if Typescript had insisted to get accepted into the Emca standard before widespread adoption and promotion by Microsoft; it would probably still stay in the 'experimental' stage.
It's wasn't just the semi-conductor manufacturers either.
The PRC had the supply chain from the bottom up (to some extent funded by the western consumers and corporations), whereas the US is trying to get reindustrializd from the top down, without first building a solid fundamental. To make the tough jobs easy, you must have the easy jobs done well first.
It has been common sense in real estate investing that the increase in density drives the land price higher (thus the housing price per squire foot). But there is a difference between the density increase of housing units and the density increase of the population. The land price increases only to the point that the added housing capacity is 'fully employed.' And that can be measured by the vacancy rate. When the vacancy rate is low, more density will lead to higher property prices.