segfaultbuserr

> This is not true for any upstream Linux kernel driver.

This is very true for at least a portion of upstream Linux kernel drivers.

> They are fully open source

True.

> fully controlled by the community

False (Of course, this claim is based on my belief that source code access is insufficient to do driver development, hardware datasheets are not just nice to have but mandatory for a true free operating system. If you disagree, nothing more can be said).

The upstream Linux kernel has absolutely no requirement that the contributed hardware drivers must include public documentation. In fact, many are written by vendor-hired contractors, or by independent embedded system companies who make computer gadgets based on these chips (so they have a business relationship with the vendor that give them datasheet access).

If you want to do any low-level work on these kinds of drivers independently, it almost always involves trial-and-error and educated guesses.

> and not subject to any NDAs to work on. The vendor can only exert control in the form of reviews and open maintainership. This is the case for both AMD and Intel GPU drivers.

Sure, the drivers themselves are not subject to any NDAs to work on, but hardware vendors often maintain a de-facto control - because they are in possession of technical advantages not available to outsiders, in terms of NDAed information and in-house expertise. Although theoretically everyone is free to participate, and it often happens, but when 80% of the experts are programmers with privileged information, it's difficult although not impossible for an outsider to join the development effort (it's no surprise that most outsider contributions are high-level changes that do not directly affect hardware operations, like moving away from a deprecated kernel API, fixing memory leaks, rather than, say, changing the PLL divider of the hardware's reference clock).

> For numbers, Arch Linux bundles some ~7.5k loadable kernel drivers (which is a subset of all available, but AUR only has 8 out-of-tree drivers, out of which two are proprietary and 2-3 are community-led. "vendor-controlled" drivers are an extreme outlier on Linux.

As a contributor to the Linux kernel, my personal experience is, drivers that contains code similar to the following are not rare:

    uint8_t registers[] = {
        0xFF, 0xFE, 0xEA, 0x3C, 0x5A, 0x6A,
        0x01, 0x02, 0x3A, 0x4D, 0x55, 0x66
        /* many lines */
    };

    /* initialize hardware */
    write_registers(device_ctx, registers);

I bet at least 10% of device drivers (or as high as 25%?) are written with privileged information and they're almost impossible for independent developers to work with (other than making educated guesses) due to incomplete or NDAed documentation. Datasheet access is the only way to interpret the intentions of this kind of drivers. Even with macro or bitfields definitions - which is better than none, the exact effect of a register is often subtle. Not to mention that hardware bugs are common and their workarounds often involve very particular register-write sequences - and that tend not to be publicly documented. Sometimes, even firmware binary blobs are embedded into the source code this way, and the code is almost always contributed by a vendor who actually knows what the blob is doing. If I was asked to do some development on top of an existing driver but without hardware documentation, I would refuse it every single time.

Note: This paper was only the design of the experiment. The actual experiment was performed later and it was indeed successful. Result was published in the journal Classical and Quantum Gravity.

* Gravitational starlight deflection measurements during the 21 August 2017 total solar eclipse

https://arxiv.org/abs/1802.00343

Surely, there are many realistic ways to abuse this powerful technology, the creation of a self-aware Paperclip Maximizer is not necessarily required.

I stand corrected. If it's already suboptimal in practice to begin with, the hack does not more it more suboptimal... Still, disabling large BAR size is still sub-optimal...

> The driver is not bypasses. This is a patch to the official open-source kernel-driver where the feature is added, which is how all upstream Linux driver development is done. [source code modification] is a weird way to describe software engineering. Making the code available for further development is kind of the whole point of open source.

My previous comment was written with an unspoken assumption: Hardware drivers tend to be very different from other forms of software. For ordinary free-and-open-source software, the source code availability largely guarantees community control. However, the same often does not apply to drivers. Even with source code availability, they're often written by vendors using NDAed information and in-house expertise about the underlying hardware design. As a result, drivers remain under a vendor's tight control. Even with access to 100% source code, it's often still difficult to do meaningful development due to missing documentation to explain "why" instead of "what", the driver can be full of magic numbers and unexplained functionalities, without any description other than a few helpers functions and macros. This is not just a hypothetical scenario, this situation is encountered by OpenBSD developers on a daily basis. In a OpenBSD presentation, the speaker said the study of Linux code is a form of "reverse-engineering from source code".

Geohot didn't find the workaround by reading hardware documentation, instead, it was found by making educated guesses based on the existing source code, and by watching what happens when you send the commands to hardware to invoke a feature unexposed by the HAL. Thus, it was found by reverse-engineering (in a wider sense). And I call it a driver bypass, in the sense that it bypasses the original design decisions made by Nvidia's developers.

> [turning off IOMMU] is not a P2PDMA problem, and just a result of them not also adding the necessary IOMMU boilerplate, which would be added if the patch was done properly to be upstreamed.

Good point, I stand corrected.

I'll consider stop calling geohot's hack "a bypass" and accepting your characterization of "driver development" if it really gets upstreamed to Linux - which usually requires maintainer review, and Nvidia's maintainer is likely to reject the patch.

> [large BAR] is an expected and "optimal" system requirement.

I meant "turning off (IOMMU && large BAR)". Disabling large BAR in order to use PCIe P2P is a suboptimal configuration.

Both can be true at the same time.

The world's superpowers enforce nuclear non-proliferation mainly because it allows them to keep unfair political and military advantages to themselves. At the same time, one cannot deny that centralized weapon ownership made the use of such weapons more controllable: These nuclear states are powerful enough to establish a somewhat responsible chain of command to avoid their unreasonable or accidental uses, and so far these attempts are still successful. Also, due to the fact that they are "too big to fail", they were forced to hire experts to make detailed analysis on the consequences of nuclear wars, and the resulted MAD doctrine discouraged them from starting such wars.

On the other hand, if the same nuclear technologies are available to everyone, the chance of an unreasonable or accidental nuclear war will be higher. If even resourceful superpowers can barely keep these nuclear weapons under safe political and technical control (as shown by multiple incidents and near-misses during the Cold War [0]), surely a less resourceful state or military in possession of equally destructive weapons will have even more difficulties on controlling their uses.

At least this is how the argument goes (so far, I personally take no position).

Of course, I clearly realized that centralized control is not infallible. Months ago, in a previous thread on OpenAI's refusal on publishing technical details of GPT-4, most people believed that they were using it as an excuse to maintain a monopolistic control. Instead, I argued that perhaps OpenAI truly values the problem of safety right now - but acting responsibly right now is not an indication that they will still act responsibly in the future. There's no guarantee that the safety considerations will eventually be overridden in favor of financial gains.

[0] https://en.wikipedia.org/wiki/Command_and_Control_(book)

> surely it's better to have distributed AGI than to have AGI only in the hands of the elites.

The argument of doing so is the same as Nuclear Non-Proliferation - because of its great abuse potential, giving the technology to everyone only causes random bombings of cities instead of creating a system with checks and balances.

I do not necessarily agree with it, but I found the reasoning is not groundless.

Which is why politicians are going to enforce systematic export regulations to defend the "free world" by stopping “terrorists", and also to stop "rogue states" from using AI to oppress their citizens. /s

Jump to Sub-Routine?

6800: http://www.8bit-era.cz/6800.html

6502: http://www.6502.org/tutorials/6502opcodes.html#JSR

PDP-11: https://programmer209.wordpress.com/2011/08/03/the-pdp-11-as...

Motorola 68000: https://mrjester.hapisan.com/04_MC68/Sect05Part05/Index.html

Except that in the computer hardware world, the 1250 kVA transformer was used not because of shortage, but because of the fact that making a 1250 kVA transformer on the existing production line and selling it as 200 kVA, is cheaper than creating a new production line separately for making 200 kVA transformers.

It's more difficult to split your work across 6 GPUs evenly, and easier when you have 4 or 8 GPUs. The latter setups have powers of 2, which for example, can evenly divide a 2D or 3D grid, but 6 GPUs are awkward to program. Thus, the OP argues that a 6-GPU setup is highly suboptimal for many existing applications and there's no point to pay more for the extra 2.

No. The Nvidia A100 has a multi-lane NVLink interface with a total bandwidth of 600 GB/s. The "unlocked" Nvidia RTX 4090 uses PCIe P2P at 50 GB/s. It's not going to replace A100 GPUs for serious production work, but it does unlock a datacenter-exclusive feature and has some small-scale applications.

> but there's nothing "suboptimal non-default options" about it

If "bypassing the official driver to invoke the underlying hardware feature directly through source code modification (and incompatibilities must be carefully worked around by turning off IOMMU and large BAR, since the feature was never officially supported)" does not count as "suboptimal non-default options", then I don't know what counts as "suboptimal non-default options".

> I find it baffling that ideas like "govern compute" are even taken seriously.

It's not entirely unreasonable if one truly believes that AI technologies are as dangerous as nuclear weapons. It's a big "if", but it appears that many people across the political spectrum are starting to truly believe it. If one accepts this assumption, then the question simply becomes "how" instead of "why". Depending on one's political position, proposed solutions include academic ones such as finding the ultimate mathematical model that guarantees "AI safety", to Cold War style ones with a level of control similar to Nuclear Non-Proliferation. Even a neo-Luddist solution such as destroying all advanced computing hardware becomes "not unthinkable" (a tech blogger gwern, a well-known personality in AI circles who's generally pro-tech and pro-AI, actually wrote an article years ago on its feasibility through terrorism because he thought it was an interesting hypothetical question).

Ironically, USB SS is more implementable than USB HS without a dedicated PHY. USB SS's PHY is just standard CML differential signaling used for almost all modern high-speed protocols like PCIe or SATA (but with an LFPS extension for link negotiation), most FPGAs already have built-in support for it. Meanwhile USB HS's PHY is a completely non-standard one: it's LVDS-like but the signals are not fully differential, it's half-duplex and needs bus arbitration, etc - only USB HS PHYs speak this odd language.

Of course, follow the best practices if you want to be really sure, e.g. set the password field to "!" so it's invalid, set the shell to /sbin/nologin, set the home directory to /dev/null (doesn't really do anything but it's a convention), etc, etc, etc. The "must have password" policy is for preventing accidental mistakes by people who don't know anything about what we just said, and my experience is that it's an effective one.

"No password = locked account" is today's default policy on most systems, for a reason.

I can't give any detail, but the solution to my problem involves k-variate k-nomial multinomial coefficients [1]. It's a generalization of the binomial coefficients to high-order scenarios such as trinomial coefficients, quadrinomial coefficients, etc. In other words, from a Pascal triangle to a Pascal pyramid, to a Pascal hyperpyramid.

[1] https://oeis.org/wiki/Multinomial_coefficients

OEIS solves real-world problems! One time I needed to optimize accesses to a data structure in my code. By trying out a few examples, I found the optimal order of iterations followed a particular number sequence, but I had no idea on how it could be deduced or calculated analytically. I entered the few examples I had into OEIS and found the solution. The solution involves graduate-level combinatorics and there was no way that I could solve it.

Thanks Neil Sloane and OEIS.

Historically, it was done for end-user convenience. Traditionally, each project has two separate sources, one is the actual development repository, strictly for use by developers. The next is the source tarball for end-user installation, pre-generated by developers by preprocessing the source repo - such as autotools script generation, gettext translation file generation, etc. The idea was that the end users were running on many flavor of incompatible Unix systems, so installing the full development tools such as autotools or CVS/SVN could be inconvenient. To avoid those troubles, developers pre-generate tarballs with necessary installation scripts such as ./configure for user-friendliness - so source tarballs are installers in a sense, at the middle way between actual source and pre-complied binary. On the other hand, because these scripts are machine-generated and are extremely sensitive to small chances to Makefiles, they should not pollute the canonical source tree, so they're not included in the source repository. Occasionally, under the strict Cathedral style of software development, the canonical source tree may even be private under exclusive access by the core team, end users only have access to release tarballs.

Nowadays, the repo-tarball split is largely unnecessary, but the practice remains. The xz incident became a wake-up call that the Reproducible Build movement focused on binary reproducibility, but have so far ignored tarball reproducibility. Hopefully, this problem will be addressed by the community in the future.

As the original submitter of this URL, I'm impressed.

> This seems ridiculous on its face

Chip designs routinely use energy metrics like picojoules per bit to express the hardware's power budgets and efficiencies, generalizing these kinds of figure of merit to software seems natural. While I doubt that running a particular version of software can automagically make a computer "green" (If WebKit becomes faster, users are simply going to open more tabs), but I think this can be a reasonable and meaningful concept within a clear technical context.

To make it more "interesting", implement it as a smart contract on the blockchain, so an adversary can also choose to exploit software vulnerabilities for profit...

> I think I understand GA, but I knew I did not understand quaternions after working through lectures and problems.

Most physicists stopped using them at the end of 19th century for the same reason...

> More than a third part of a century ago, in the library of an ancient town, a youth might have been seen tasting the sweets of knowledge to see how he liked them. He was of somewhat unprepossessing appearance, carrying on his brow the heavy scowl that the "mostly-fools" consider to mark a scoundrel. In his father's house were not many books, so it was like a journey into strange lands to go book-tasting. Some books were poison; theology and metaphysics in particular they were shut up with a bang. But scientific works were better; there was some sense in seeking the laws of God by observation and experiment, and by reasoning founded thereon. Some very big books bearing stupendous names, such as Newton, Laplace, and so on, attracted his attention. On examination, he concluded that he could understand them if he tried, though the limited capacity of his head made their study undesirable.

> But what was Quaternions? An extraordinary name! Three books; two very big volumes called Elements, and a smaller fat one called Lectures. What could quaternions be? He took those books home and tried to find out. He succeeded after some trouble, but found some of the properties of vectors professedly proved were wholly incomprehensible. How could the square of a vector be negative? And Hamilton was so positive about it. After the deepest research, the youth gave it up, and returned the books. He then died, and was never seen again. He had begun the study of Quaternions too soon.

- Oliver Heaviside, Electromagnetic Theory

It's a combination of both aspects.

The first point is that LPDDR5 chip's operating frequency today has reached an all-time high of 9600 MT/s, and the latest off-the-shelf laptops (Intel Meteor Lake) are running at 7467 MT/s. This kind of high bandwidth is especially preferred in laptops for improved graphics and gaming performance. The iGPU has to compete with CPU for system DRAM bandwidth (which is already only a fraction of what a dedicated GPU has), every GB/s helps. Meanwhile, SO-DIMM is hitting its physical speed limit due to signal integrity issues (I heard that the impedance mismatch at the connector is too great to go faster). So yes, if you want high operating frequency, soldered RAM is the only option.

The second point is that, it's not always needed for every laptop, of course it's just a matter of tradeoff, many users would prefer lower DRAM bandwidth in exchange for better upgradability. On the other hand, hardware vendors can use this technical limitation as a justification to design machines with non-upgradable memory. You hit two birds with one stone: you can achieve better performance and force customers to pay extra for RAM at the same time.

If CAMM sees mass adoption, it's still up to the vendor to decide if they're willing to actually provide upgradability - but at least it'll be made possible at the technical level.

Emacs has Evil Mode for simulating a modeful editor with vi-style keybinding. Vim now has an extension to do the opposite thing. It would be extra amusing if it supports Emacs-style keybindings (but it doesn't).

It's evil-mode time.

If I recall correctly, these integrated "AI accelerators" from both Intel and AMD are actually rather underpowered in comparison to an actual GPU (even the iGPU), at least in their current forms. So they don't have any performance advantage, but was put in place for power efficiency.

> Can you tell us a specific, unnecessary burdensome regulatory rule that you feel is holding back progress?

+1. There are so much flamewar threads but I haven't seen a single technical discussion on a supposedly technical website. Recently I've seen a book review about it. [0] I haven't evaluated the merits of the author's arguments, so I can't say I endorse it unconditionally, but there's a lot of interesting food for thought.

In summary, the author's claims are that regulations are unnecessarily strict mainly because of the ALARA safety guidelines. For regulatory purposes, safety risks must be minimized to As Low As Reasonably Achievable. As a result, whenever a new technology becomes available, the safety standard also increases in responsive. By design, the cost is always high in spite of technological improvement.

> An example was a prohibition against multiplexing, resulting in thousands of sensor wires leading to a large space called a cable spreading room. Multiplexing would have cut the number of wires by orders of magnitude while at the same time providing better safety by multiple, redundant paths. A plant that required 670,000 yards of cable in 1973 required almost double that, 1,267,000, by 1978, whereas “the cabling requirement should have been dropping precipitously” given progress at the time in digital technology.

Sometimes the regulation involves considering certain failure modes that are physically impossible:

> Another example was the acceptance in 1972 of the Double-Ended-Guillotine-Break of the primary loop piping as a credible failure. In this scenario, a section of the piping instantaneously disappears. Steel cannot fail in this manner. As usual Ted Rockwell put it best, “We can’t simulate instantaneous double ended breaks because things don’t break that way.”

A related issue is that the currently accepted principle of radiation safety is a linear, no threshold model. All ionizing radiation is seen as harmful, no matter how low, in spite of the scientific evidence that suggests a low level of ionizing radiation has a negligible effect when it's within the DNA's self-repair capabilities. The result is that radiation safety regulations can often be unnecessarily strict across the entire discipline of nuclear science.

> A forklift at the Idaho National Engineering Laboratory moved a small spent fuel cask from the storage pool to the hot cell. The cask had not been properly drained and some pool water was dribbled onto the blacktop along the way. [...] The Bannock Paving Company was hired to repave the entire road. Bannock used slag from the local phosphate plants as aggregate in the blacktop, which had proved to be highly satisfactory in many of the roads in the Pocatello, Idaho area. After the job was complete, it was learned that the aggregate was naturally high in thorium, and was more radioactive that the material that had been dug up, marked with the dreaded radiation symbol, and hauled away for expensive, long-term burial.

> [...]

> One the biggest labs is Argonne outside Chicago. At Argonne, they monitor people going in and out of some of the buildings for radiation contamination. The alarms are set so low that, if it’s raining, in coming people must wipe off their shoes after they walk across the wet parking lot. And you can still set off the alarm, which means everything comes to the halt while you wait for the Health Physics monitor to show up, wand you down, and pronounce you OK to come in. What has happened is that the rain has washed some of the naturally occurring radon daughters out of the air, and a few of these mostly alpha articles have stuck to your shoes. In other words, Argonne is monitoring rain water.

Yet another factor is that strict regulations on nuclear reactors makes research and development difficult, as they're subject to the same stringent regulations, including building a complete model of all possible failure modes.

> Many questions arise during NRC design review: how a plant will handle the failure of this valve or that pump, etc. A natural way to answer these questions would be to build a reactor and test it, and for the design application to be based in large part on data from actual tests. [...] But under NRC rules, you cannot build even a test reactor without a license, and you can’t get a license until all such questions are resolved.

Overall, the author argued that the current regulation is founded on the false promise that a nuclear power plant can never fail with an unrealistic safety target. Instead, radiation release should be accepted as an inevitable but very rare occurrence.

> Instead of selling a lie that a radiation release is impossible, the industry should communicate the truth: releases are rare, but they will happen; and they are bad, but not unthinkably bad. [...] Rather than saying “a [plane] crash will never happen,” they put data-collecting devices on every plane so that when one inevitably does crash, they can learn from it and improve. This is a healthy attitude towards risk that the nuclear industry should emulate.

[0] https://www.lesswrong.com/posts/ThvvCE2HsLohJYd7b/why-has-nu...

I think both sides have a point, it's just a matter of perspective. One person's "drawing a black triangle" can be another's "black triangle moment". It's turtles all the way down.

From the perspective of an experienced Vulkan programmer, it's only a basic tutorial on creating an empty stub project, which is useless in itself as the real work of creating a powerful 3D engine has yet to start. But from the perspective of a new graphics programmer without any prior Vulkan knowledge, creating a stub project capable of drawing a triangle is already an accomplishment in itself. In OpenGL, the same thing is possible in 50 lines of code, compared to a stub Vulkan project that explicitly defines every component using thousands lines of code. Upon finishing it, one would finally have an understanding of how every part comes together, which enables further development. It would be then possible to draw many different kinds of object on top of this stub framework. In this sense, it fits the definition of:

> accomplishments that take a lot of effort to achieve, but upon completion you don’t have much to show for it only that more work can now proceed.