lgeek

> You won't get very close to any of the running reactors

They've all been decommissioned. #3 was the last one to shut down in 2000.

On a related note, this Youtube user [0] has videos from what appear to be tours inside units 2, 3 and 4 (the one which suffered the meltdown in '86). The one from the reactor hall in unit 2 [1] is particularly interesting.

[0] https://www.youtube.com/user/Thallium208/videos [1] https://www.youtube.com/watch?v=Oe_zzTQFV3o

> For general user applications, yeah, performance isn't that big of a deal.

Maybe if you use recent, powerful machines and don't particularly care about energy efficiency. In my experience with less powerful machines, the applications which tend to be noticeably slow are exactly the widely used 'general user applications': of the ones I use, Firefox, Chromium, LibreOffice and Thunderbird.

Looking at the RISC-V spec, you probably should be using the AUIPC instruction to address data in your .text, .data or .bss sections. As a bonus, your code becomes position-independent so you can actually use it in shared libraries. To use arbitrary 32-bit and 64-bit pointers known at compile-time (which should be pretty rare), you also have the option of loading them from memory, i.e. using AUIPC to generate a pointer to the value in your .text and then loading it to a register in addition to your approach.

> 32-bit fixed encoding makes the decoder simple, but creates the same load-store problem as on SPARC - hello non-existent, synthetic instructions!

I'm not familiar with this. Could you explain the problem or point me in the right direction for background info?

Well, it's definitely fast enough not to notice excessive latency in the terminal and to run simple applications, but the instructions are interpreted so expect a serious slowdown compared to recompiling or dynamically translating the code.

On the other hand, this makes the code portable and indeed the 32-bit and 64-bit targets work pretty well even on my ARM AArch32 machine.

I can see some pretty strong effects (and false positives) from what seem to be TLB misses. On my system, on Firefox, the L2 size is not detected correctly if transparent huge pages are enabled, but on Chromium it is. I'd like to take a closer at what's going on, but the tooling for performance-related debugging in browsers seem to be more or less missing. I've opened a pull request for some fixes to the C implementation though.

I'm not saying that he's necessarily dropped it or that it's okay for the CS rep to have accused him of that, but my 4+ year old Galaxy S3 has the same sort of bubbles in two corners on which it has been dropped so I get why that was the first question asked.

> we believe that the benefits of open source we enjoy in the software world can be applied to the hardware world

In my opinion open source hardware IP has at least two major limitations compared to software, which make it significantly less useful or important to end users. I guess your preference for open source rather than copyleft already hinted that the benefits are mostly for the ecosystem rather than the users. The first one is that even though you can modify the design, you have no practical way of using your modified design (at least in this context, because FPGAs are slow and expensive and high performance SoCs don't fit anyway).

The second limitation is that it is impractical to audit the hardware to determine whether you have actually received the unmodified open source design. For software this can be achieved using reproducible builds or just by compiling it for yourself.

Open source hardware boards (as opposed to IP) have some of these limitations as well, however both can be overcome by a hobbyist with a modest budget.

Use higher airflow (including a larger nozzle) and lower temperature. The temperature calibration might be a bit off if the soldermask gets damaged by air at 300°C. Preheating, which has already been mentioned, also helps.

Fair enough, some instructions have many variants. But I work with ARM assembly almost daily and I still wouldn't remember that, for example, 'VQRDMULH' is a real instruction and it stands for 'Vector Saturating Rounding Doubling Multiply Returning High Half'.

> Here's a handy heuristic: if somebody claims to know every x86-64 instruction (or even every x86-32 instruction), you can be at least 90% sure they're lying.

I very much prefer ARM myself, but you can probably apply the same rule of thumb to it. There are upwards of 400 instructions both in AArch32 and AArch64, with a fair number of differences between the two.

Edit: I've also posted a breakdown of the immediate limitations for ARM in this thread. It's not that complicated when sticking to the standard instructions.

> I never felt more like stabbing myself than when trying to cipher out exactly which immediate values are possible on ARM, and which are not.

It depends if you're compiling for ARM or Thumb. The main rules are:

ARM and 32-bit Thumb instructions: 12 bits for arithmetic data processing instructions and load/store, 8bits with even rotate right for bitwise data processing instructions + MOV and MVN

16-bit Thumb: 3 bits for arithmetic instructions with Rd != Rn, 5 bits for shifts (so the whole range is covered) and load / store (but shifted left by the size of the data, i.e. the maximum offset for this version of LDR is (0x1F << 2) = 124), 8 bits for arithmetic instructions with Rd == Rn, SP-relative loads / stores and literal loads.

I doubt x86's popularity has much to do with its instruction set at this point. In particular, the variable length instructions are a pain for decoders (both hardware and software).

I've collated the answers to some of the questions:

* How often do you encounter encryption? The most common answer is 'often'. Germany does not collect this statistic. Czech Republic and Hungary: 'rarely', Latvia has both 'often' and 'almost always' in bold, UK 'almost always'.

* Online encryption: most common one is e-comms (everywhere but Italy), followed by TOR (everywhere but Hungary and Poland). Denmark, Finland, Germany and the UK reported encountering all types of encryption on the form.

* Offline encryption: it's not very clear what is an encrypted device (it includes computers) and what is an encrypting application (they give disk encryption tools as examples), but all countries except Poland selected devices and all countries except Italy selected applications

* It sounds like the accused can only be compelled to disclose passwords or keys in the UK, but Italian LE would also like that very much, despite having reported that 'the current national law allows sufficiently effective securing of e-evidence when encrypted'.

* In Croatia, Latvia and Poland they consider that the current national laws don't allow effective securing of encrypted evidence. The answer to this question is not available for Czech Republic and the UK.

A few other interesting things I've noticed:

Croatia: 'There is no practical experience' regarding 'intercepting/monitoring encrypted data flow'; 'Tools for decryption are used in less complex case [...]. Foreign companies’ services were not used so far.'

Czech Republic: 'Additional intentional encryption is quite rare in most cases although encrypted mobile phones are more and more popular among members of certain organized crime groups.'

Denmark: 'The main issue with trying to decrypt encrypted data is of a technical nature. Furthermore the equipment needed to break encryption is costly and the process itself takes a lot of time.'; 'In general terms, we can inform you that commercial software is among the tools used to decrypt data'; 'Decryption typically requires large hardware resources (processing power) as the encryption offered by service providers is very strong.'

Estonia: 'The main problem is that communication or data are encrypted and if key is not available, it is not possible to decrypt them.'

Finland: 'In case of full-disk encryption, which is rare, we have to either use brute force attacks, or try to obtain the credentials some other way'; 'We do not usually use private sector companies for decryption purposes, but of course a large part of the software/hardware used are commercial products'; 'Wireless criminal intelligence gathering can be challenging, because the LE sector has limited legal rights to gather for example WIFI data'; 'Sometimes insufficient computational capacity of our password-breaking platforms make the decrypting process too lengthy'; In general they talk about C&C servers for botnets quite a lot.

Germany: Regarding intercepted encrypted comms: 'In many cases, analysis of actual communication content is not feasible.', 'A regulation to prohibit or to weaken encryption for telecommunication and digital services has to be ruled out, in order to protect privacy and business secrets.'

Hungary: it sounds like they gave the form to the wrong dept? 'Our unit is not dealing with decryption, therefore we do not have any practical experience in this field.', 'Our unit is not dealing with such techniques.'

Italy: covered in the OP

Latvia: 'LV sees as clear added value of EC3’s encryption/decryption platform; LV also highly values the availability of the Europol Platform for Experts.';

Poland: mostly covered in the OP, I'll add 'The specialised computers (GPU clasters[sic]) which can decrypt encrypted e-evidences are very expensive.'

UK: It reads like a polished PR piece, at least relative to the others. Provides non-answers. It's probably worth taking a closer look. For example to 'Under your national law, is it possible to intercept/monitor encrypted data flow to obtain decrypted data for the purposes of criminal proceeding?' they responded with 'Section 17 of the Regulation of Investigatory Powers Act 2000 prevents intercepted material from being used as evidence in legal proceedings.', which doesn't actually answer the question.

> Is there any ARM SOC yet that ARM has said can run Linux out of the box?

That is not how this works. ARM doesn't design any SoCs sold to the general public. They design some specifications, such as the ARM architecture specs, a number of implementations (i.e. the Cortex cores) and a number of other IP blocks such as cache controllers, memory controllers, SD/MMC controllers, UART controllers, interconnects, DMA engines, MMUs and, yes, GPUs. AFAIK all of these apart from GPUs are supported in mainline Linux due to drivers written by ARM, which is why I've said that all their IP except GPUs is supported properly.

Now, to actually create SoCs, other companies such as Allwinner, NVIDIA, Samsung, etc, buy a license either for the architecture and use their own implementation (e.g. NVIDIA Denver) or they buy a license for the ARM implementations (e.g. the Allwinner A64 which uses Cortex-A53). These companies can then license a subset of the other ARM IP blocks, they can create their own, or they can license them from other companies. So you end up with SoCs which are either partly or completely not ARM IP, hence not ARM's responsibility to support as a complete unit. If you're looking to blame someone, blame whoever designed the SoC.

> Drivers for all the hardware bits are tied tightly to Android.

The GPU and video accelerators have userspace bits which are typically proprietary and Android specific. This is what I was saying is indeed annoying but not that much of a problem. The GPU on ARM SoCs only provides OpenGL(ES) acceleration, while graphics output, framebuffers, and even the hardware support for XV (video scaling, colorspace conversion) is usually implemented in different IP blocks with available drivers. Software decoding for 1080p and smaller video is fast enough on most SoCs.

> ARM SOCs are all different and tightly closed.

They're all different indeed, but not necessarily tightly closed. You can get the reference manual for a whole bunch of SoCs, including NVIDIA Tegra K1 and X1, the Freescale i.MX series, the TI Sitara series and most Allwinner SoCs (ha). These normally exclude the graphics/video accelerators, but everything else needed to have a usable system is typically included.

> Which ARM SOC can you run on Linux without support from third party open source developers?

Things get really blurry between drivers officially supported by the vendor, drivers mainlined by the employees of these companies in their free time, and drivers written by the vendor but mainlined by the community. AFAIK, at least the Tegra series and the X-Gene based APM SoCs are in the first category.

> Only the rasberry pi works on the latest mainline and that is due to the work done by the foundation

Well, that's simply not true. I personally use a Cubieboard 2 (Allwinner A20), Jetson TK1 (Tegra K1), Acer Chromebook 13 (Tegra K1) and APM X-C1 (APM883208) on mainline. On TK1, even the GPU is supported via nouveau and APM883208 doesn't have one.

Wasn't the mainlining work for RPi mostly done by Eric Anholt, who (surprise!) works for Broadcom, the makers of the SoCs they use?

The Samsung Chromebook Pro looks pretty promising (RR3399, 4GB DRAM, 2K screen), but it hasn't been officially released yet.

It's annoying there's no Free driver stack for the Mali GPUs, but pretty much all other ARM IP is supported just fine in mainline Linux. Calling it a 'sorry state of open source on ARM' seems disingenuous.

> specs are on-par with a 2-year old smartphone flagship

Cortex-A53 is a low cost, energy efficient, slow, in-order implementation. I don't think it was ever used as the main core in a flagship smartphone. Something like a 2012 ODROID-X2 SBC with its Cortex-A9 cores should have no trouble outperforming it, but it doesn't support AArch64.

> Given Allwinner's history of GPL skirmishes and backdooring

On the other hand, the linux-sunxi community does a pretty good job of bringing mainline support for Allwinner SocS and they're working on the A64. That's probably the longer term plan for the creators of this laptop.

It's not that in this case, this is plain binary translation and not cycle accurate emulation. QEMU is super slow on x-to-x translation as well (something like 8x to 80x slowdown). Its translator is inefficient (for the sake of portability, the source native code is first translated to an IR and then the IR is compiled to target native code with limited optimisation) and it emulates all floating point instructions in software.

And these guys ship an x86 to ARM DBT which they claim has significantly better performance: https://eltechs.com/product/exagear-desktop/. I haven't tried it. QEMU is the slowest DBT system I'm aware of, so it's entirely plausible. Translating from a strongly ordered architecture to a weakly ordered architecture is big challenge, I wonder if they handle threads efficiently.

NVIDIA had about 5 different generations of Tegra before the K1 [1]. The A15-based K1 (T124) came before the Denver-based K1 (T132) AFAIK. Both are very nice and a clear improvement over the previous generations. Denver is a bit inconsistent in its performance, but on average it dominates A15s and A57s. Nexus 9, however, has very poor thermal design and can only dissipate a small fraction of the heat output of the T132.

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

> If you really need performance, not only "in some benchmarks" then there is no alternative to Intel.

Different microarchitectures perform better on different workloads, nothing new here. AMD's CMT works very well on control / integer bound workloads. Their main disadvantage is that the Piledriver CPUs are 32nm and therefore lose on energy efficiency.

> The thinner the battery, the closer the positive and negative terminals are.

Absolutely false. All lithium ion batteries are made of 4 paper thin layers: two electrodes and two separators. These are cut in narrow strips and folded on themselves many times over, even in a thin battery. A thinner battery will simply have fewer folds. The distance between the two electrodes is given by the thickness of the separators and it has nothing to do with the thickness of the cell.

Here's a teardown: https://youtu.be/uI1eRy0uBI8?t=958 (possibly NSFW-ish language).

Hmm, what are the advantages of using this bootloader over U-Boot? Or is it simply that U-Boot doesn't support Ethernet or some other peripherals on the A64 SoC?

Hmm, I know the factory firmware can be reliably crashed by sending malformed data over the network. I wonder if there's a RCE hidden somewhere in there which might allow bootstrapping to Linux over the network.

Somewhat off topic, but I wish NVIDIA published more information about Denver's DBO and the reasoning behind some design decisions. For example the company line is to just generate 'decent code' and let the DBO take care of it [0], but that clearly doesn't always work in practice [1], which requires a lot of trial & error and some reverse engineering to generate good code for it. Also, the decision to always invalidate the translation when writing to an executable page (or whatever other super slow operation is done in that case) seems odd (and affects the performance of some JIT approaches) since ARM software is expected to explicitly flush the caches when modifying code anyway.

[0] https://www.youtube.com/watch?v=oEuXA0_9feM

[1] https://github.com/ssvb/tinymembench/wiki/Nexus-9-(Tegra-TK1...

> Since ARM moved to ARMv8, I groaningly refer to v8 as "x86 v2"

I'll have to disagree, I think ARM mostly did the right thing with the A64 instruction set. The AArch32 instruction sets were just getting ridiculous (just having multiple instruction sets for one architecture is pretty messed up), with A32, T32 and a bunch of other extensions (ThumbEE, Jazelle) which pretty much no one used. In addition, the A32 and T32 instruction sets have grown organically over time, with new instructions being crammed in any unused / invalid space, which is how we ended up with one encoding doing this one thing, except if one register is the SP or PC, then that is a whole other instruction or with immediate values being split up over 2, 3, 4 fields. Also, a few features had turned out to be pretty bad ideas: for example access to the PC as a general purpose register is overly complicated to implement in OOO cores (verification cost) and comes with performance penalties, but it still had to be supported; the IT instruction is another fun one, especially in the context of dealing with exceptions.

A64 pretty much takes the set of instructions which has emerged over time, removes the bits which are not suitable any more or were bad ideas in retrospect, fits them cleanly in a new encoding space and removes some of the flexibility which was getting in the way (e.g. VFP having either 16 or 32 double precision registers). I expect AArch32 to be gone from most high performance implementations in a few years, with a software DBT option remaining available for legacy software which still hasn't been ported, which is when the implementers will be able to fully benefit from having a simplified AArch64 compared to AArch32.

I was wondering how come people suddenly started starring the repository.

I'm around to answer questions if there are any.

I've tried to use blueproximity at some point (mostly for convenience because I sometimes forget to lock my screen), but the range of BT devices is too large for comfort. I could be anywhere in my flat or in the medium-sized open plan office at work and the phone in my pocket would still be in range.

I remember writing a script at some point to lock the screensaver in case of high acceleration or if the laptop is tilting by more than a few degrees. The idea was to lock it if was snatched (or just moved around).

However, that would only be effective against a petty thief and not against a forensic team. In that case you'd probable want to additionally flush the filesystems (if you care about data integrity in case of a false positive), overwrite the encryption keys in memory (maybe on disk as well, but then there's no coming back without a backup) and shut down. I wonder if the init scripts prompting for the password, cryptsetup and the LUKS subsystem have been designed to always overwrite copies of the entered password and decrypted keys ASAP.

> And until android has fake permissions I won't install messenger.

Cyanogenmod has Privacy Guard, which is pretty much that.