holowoodman

32bit support isn't just bad bloat due to larger pointers.

Only doing 32bit and not doing amd64/x86_64 is also leaving a lot of performance on the table:

x86 traditionally has very few registers to work with, amd64 gives you quite a few more general purpose registers, so your hand-fiddled assembler will be faster, and if you use compiled code, your compiler will have an easier time with optimizations, faster function calls due to more register arguments, less register-to-memory spills and more execution station parallelism.

Memory use is also an important point, your 32bit application will be limited to at best 4GB per process, usually more like 2GB (due to the kernel/user boundary at 2/2GB, absent weird tricks). With games currently being multiple times that size, you have to swap out assets and load new ones very frequently, which is why loadpoints are getting more common and level design has to add more corridors and doors to support those load points and segment level data into 2GB chunks.

And the newer processor features, especially SIMD stuff like AVX and SSE work better with 64bit registers, if they work at all. Many support libraries that can utilize SIMD only do so in 64bit versions. Some features aren't even available if the hardware is in 32bit mode. And compilers can do automatic SIMD conversions, but those work far better (if they work at all) in x86_64 mode because of the insufficient number of registers in 32bit mode for copying around and splitting up stuff from a SIMD register.

I think the real reason that especially game developers are opposed to amd64 is that they used to be stuck on 32bit on Windows for a long time and now have to be dragged into the future by force ;)

Actually, there are some things.

libGL/libVK for OpenGL and Vulkan support is a big one, you need that to be fitting the exact version of your kernel Nvidia driver if you are using Nvidia cards. Of course all other vendors play nice with Open Source and Mesa libs, but especially for gaming, a lot of people unfortunately still buy Nvidia. Games cannot just ship their own 32bit libGL for reasons of license and versioning.

Well, let's face it: Nobody likes the current Iranian government, and nobody wants yet another state (especially with a leadership like that) to have nukes. Just that nobody dares to do anything beyond sending strongly worded letters and time-wasting "diplomatic initiatives".

It half-way is, at least by the new chancellor Merz, who praised Israel for doing our "dirty work" in bombing Iran. And he was promptly criticized by the rest of the political establishment and the press for that.

A non-open system is not verifyable and therefore not trustable. Therefore a non-open system can never deliver privacy. At best it can attempt to trick you into believing it does.

Mostly weapons and weapons components. E.g. Israel operates a number of German-built and partially gifted submarines: https://en.wikipedia.org/wiki/Dolphin-class_submarine

Also, Israel is a trade partner, which is important because the non-western countries are hesitant to trade with them. Israel is culturally integrated into certain European institutions, in part due to German support (soccer, Eurovision, other sports).

There is also an unspoken bit of realpolitik there: Israel is still an ally to Germany, Palestine isn't, Iran isn't, Hamas isn't, etc.

So this is actually a super-nice position to be in, you can support your ally no matter what they do, while still looking contrite and morally superior by pulling the "we are Germany, we are not allowed to have a say in the matter" card.

> So when I say CIA nowadays, I'm actually thinking both mathematically irrespective of downstream application, and from the choose-your-own-compliance view.

That doesn't help anyone, because it is far too primitive.

A medical device might have a deadly availability vulnerability. That in itself doesn't tell you anything about the actual severity of the vulnerability, because the exploit path might need "the same physical access as pulling the power plug". So not actually a problem.

Or the fix might need a long downtime which harms a number of patients. So maybe a problem, but the cure would be worse than the disease.

Or the vulnerability involves sending "I, Eve Il. Attacker, identified by badge number 666, do want to kill this patient" to the device. So maybe not a problem because an attacker will be caught and punished for murder, because the intent was clear.

Security bugs always have a context-dependent severity. An availability problem in a medical device is far more severe than a confidentiality problem. In a cloud service, the same problems might switch their severity, downtime isn't deadly and just might affect some SLAs, but disclosing sensitive data will yield significant punishment and reputation damage.

That is why I think that "severity" and the usual kinds of vulnerability scores are BS. Anyone composing a product or operating a system has to do their own assessment, taking into account all circumstances.

In the context of the original article this means that it is hopeless anyways, and the maintainer's point of view is valid: in some context everything is "EXTREMELY HIGH SEVERITY, PANIC NOW!". So he might as well not care and treat everything equally. Absolutely rational decision that I do agree with.

Yes, but actually no: usually setting up those namespaces is done through a privileged daemon or suid-root binaries. Both of those are prone to root exploits, which isn't as bad as a kernel exploit, but only a 'modprobe' away. Group membership in the 'docker' group is famous for being root-equivalent.

It isn't impossible to do things right, but in practice, things are usually done badly.

Usually you draw a representative random sample for these kinds of things. You only test every bar if you detect a problem in the random sample.

Device drivers are worse if you just count the numbers. But they are usually far less exploitable because very often you need to have the corresponding hardware plugged in or even need to manipulate said hardware to provide crafted inputs. So in reality, device driver problems are almost never exploitable.

For the last 10 years or so, namespaces in Linux were the source of the absolute hightest number of local privilege escalations and sometimes even arbitrary code executions in kernel space. Building a kernel without user namespace support has been goto-advice for multiuser systems for almost as long. Ubuntu is just late to the game because they mostly have server or single-user-desktop customers.

every other world war or so...

But only a little nominal distance in a few interviews. Die Linke is still the official successor of the SED, which was the GDRs single allowed communist party. And this shows in membership and positions, which are 95% true to Moscow.

Don't you know that the US forced Russia to invade? /s

Afaik not really. The ones that scan humans are tuned for a specific proton resonance frequency, so they basically measure hydrogen density. But you get a 3D-Plot because they do a computed tomography of that density.

The chemistry NMRs are spectrographs, so you dial through a whole frequency spectrum and look at the reflected/transmitted signal. With that you get different peaks for different nuclei plus some deviations for crystal or molecular structure.

But I have to admit, that I'm a little rusty on that topic, so you might be right anyways.

You can nowadays look at a 3D-plot of internal density in an X-Ray computed tomography. On the chance that somebody mixed up an alloy that has the exact same density and X-Ray density as gold, you can try X-Ray absorption spectra which depend on nuclear resonances of different nuclei, so would conclusively prove presence and amount of non-Gold material.

And you can do activation analysis, where you activate the ingot with neutron radiation such that Gold isotopes form and decay. You then measure the decay gamma radiation spectrum and look for decay lines that are not gold but another material. This is non-destructive, but will make that ingot slightly radioactive for a while, but nothing that a few weeks of patience to wait for the decay can't fix.

Oh, and nuclear magnetic resonance (NMR) spectra would also work, but usually those machines are for very small samples in the milligram region. No idea whether there are some that could fit a gold ingot.

The official line in Germany is actually that Ukraine most probably did it: https://www.tagesschau.de/investigativ/ndr-wdr/nordstream-17... https://www.br.de/nachrichten/deutschland-welt/nord-stream-s... https://www.wsj.com/world/europe/nord-stream-pipeline-explos...

Knowledge or agreement by Selensky is unclear, but there seem to be hints. Poland might have been complicit or at least turned a blind eye and seems to have let a wanted suspect escape to Ukraine.

Well, let me tell you (from some experience) how this would have gone in good old Germany:

No mineral rights like Texas, except for the occasional lignite open-pit mining, but that is very limited to certain regions. And even then, you'd be reimbursed handsomely for your troubles and the torn down equipment and land.

Grid connection would have been easier, because the electricity company is required to provide timely and cheap connections to the next sufficient connection point. However, there are exceptions, if they can prove that they cannot get contractors, so you have to wait some time, usually two to three years after you sign the contract for the connection.

Before connection contract signing, you need to enter an auction for the price of the power you will be providing. Fixed for 20 years. However, those 20 years start at signature, so the first 2 to 3 are wasted because of no connection. And you are competing with tons of other solar installations, so you can't really predict your profits when planning. Btw. they can even fail to connect you after you already built your plant for the same reason, so you may either wait or risk it...

Then you have to get approval from the local planning bureau. For that you need a number of assessments: You need to prove that there is no environmental impact, e.g. on rare species of vermin and weeds, no impact on nearby population e.g. through noise, reflection, or other annoyances. Then you have to get approval for the land-use change, because usually you are building on land zoned agrarian use, that has to be changed (and usually can never be changed back, so the land is worthless afterwards even if you don't actually build). You have to get approval from various environmental protection agencies that certify you are not in any kind of protected zone, or if you are (half of Germany is), then you are not affecting anything important (which is a 50/50 chance). Then your plans have to be submitted for public review, where local groups of busybodies, can enter their objections. If there are objections, the approval can be delayed or denied. You can of course "bribe" the public with a few well-placed donations to local groups, or by declaring your enterprise to be open to local investment for which you then sell shares and hand our corresponding parts of your profits. This of course necessitates a change in legal form, which of course needs another few rounds with lawyers, tax advisors, the tax office and a whole lot of due diligence because you are now handing out shares to small investors, which is kind of protected and therefore complicated...

Believe me, the OP's story is very harmless compared to what this would take here, even though the above is the simplified process after a few rounds of laws that were intended to accelerate building green energy.

P.S.: You need a fence and cameras. First because no insurance will allow it without the fence, some idiot kid could climb a panel and fall. Second because there are professional solar panel thieves around here, stealing them at night by the truckload.

you forgot EDLIN

> Why would Microsoft want to kill X? It kept back the Linux desktop.

Well, we'll see what "progress" Wayland will bring. Maybe in another 15 years, when it might be halfway "done"...

> DRM is literally the 3D acceleration driver framework for Linux. It has been around for decades and is same set of drivers that are used for any sort of accelerated graphics in X.

Yes, exactly. And Wayland ignored it for years, from the start, and only later slowly adopted it as an extension.

> DMA is part of the basic architecture of modern computers.

Yes, I know.

DMA is even older and not limited to Linux or Graphics. Back in the old VESA, SGI and Windows 3.0 times, DMA was a cool new feature (but actually old even then). When Wayland was conceived, it was boring and old. Yet Wayland didn't originally include DMA buffers, just later added it as an extension when it became obvious that they had just gotten rid of a 40 year old feature that was really really necessary for modern graphics...

That is complete BS. The application doesn't talk to the graphics hardware alone and then just copy a bitmap into a Wayland buffer. You don't just magically talk to the GPU. There is this little problem called 'security', 'multiprocessing' and 'multiuser' in between.

Compositors are incompatible with one another and have totally different levels of functionality. Most compositors don't do any proper kind of security and permissions and just limit data flows in the most primitive and restrictive way possible. Using something with existing security but the possibility of cross-communication like DBUS is just easier here. Although I expect a lot of confused deputy type of exploits there...

Staging still means it is untested because not widely implemented. And still unsupported by the majority of compositors. So basically still unusable.

Also, "can become stable" is a very rare thing. Only a single-digit percentage of staging ever became stable.

Yes, but X11 has the excuse of being very old. Wayland was supposed to be a clean redesign, learning from the mistakes of the past. They learned from some mistakes, but they also completely ignored all of the good ideas, functionality and necessary additions that X11 and other systems like MacOS and Windows had.

They designed a system that was as simple as they could make it, trying to push the complexity that wasn't just bitmap-blitting onto others. And they isolated Wayland from all possibilities of making proper, compatible, common extensions. They tried to be the opposite of X11, because they recognized "push absolutely everything into the X11 server" as a mistake. Nobody ever used the XPrint extension. But they went too far, cut away all the useful stuff, all the necessary extensions, even cut away the "server" and just went with a library plus protocol. Now everyone has to reimplement their own server (compositor in wayland lingo), producing tons of busywork, splitting the community, ensuring incompatibility and pain. And everyone has to keep up to date on all the tons of necessary extra protocols that all the compositors have to implement all over again.

Yes, the same words do apply. But for different reasons.

Wayland also doesn't even remotely resemble anything that would be fit to talk to modern graphics hardware. DMA buffers and DRM (direct rendering manager, not the digital restrictions management) are an afterthought, a separate protocol that is not even all in stable yet. Vulkan usually doesn't work. Latency with Wayland got worse and won't get better because "frames have to be perfect". Tons of unnecessary blitting and latency be damned. All while actually tearing in Wayland is as bad as in X11 here.

Fixing X would require a protocol that is mostly X, but of course incompatible because you have to rip out some protocol bugs. But Wayland isn't X minus the bugs. Wayland started as a little bit of broken bitmap-pushing and a whole lot of hot air. And even with tons of extension and auxilliary protocol development, multiplied by tons of unnecessary reimplementations in tons of compositors, it isn't even where X11 was when Wayland started. Wayland fixed nothing yet, broke a lot, fragmented the community, brought pain and misery.

Tons of stuff aren't in wayland that are actually graphics and window related. Wayland just forgot about it, then later on people realized that their design was far too primitive and simplistic.

DMA buffers, color management and pixel formats, scaling and DPI, image and video capture, tons of keyboard and mouse related things, all initially forgotten, now incompatible extras that are inconsistently implemented, frequently broken and forever in beta/staging/unsupported hell...