aexaey

Nobody uses 512-QAM for WiFi, and for some good reasons:

1) it's not part of any current or draft standard;

2) it only encodes 9 bits vs. 8 bits for 256-QAM. Plugging this into GP's formula gives us:

1/3.6e-6 × 468 × 9 × 5/6 = 975 Mbit/s

3) current WiFi QAM constellations are all square [1,2], and there is no way to arrange 512 points into a square.

4) that would require an unrealistically clean channel, and give no advantage over lower-order modulations otherwise [3]

[1] https://dsp.stackexchange.com/questions/31607/why-are-qam-co...

[2] http://www.radio-electronics.com/info/rf-technology-design/q...

[3] https://upload.wikimedia.org/wikipedia/commons/thumb/6/68/QA...

There are 3 non-overlapping 2.4Ghz channels (1,6,11) for 802.11b, because of the channel spectrum shape. Not only "b" uses 22Mhz channels with is just a bit too wide, but also, due to the way how single-carrier PSK modulation works, especially on older hardware, "b" has considerable amount of spurious emissions adjacent to the main carrier that widen it even more - could be seen here as smaller "hills" to the left and right [1],[2].

802.1g/n/ac can easily have 4 non-overlapping channels (1,5,9,13) because (thanks to OFDM) channel spectrum is much neater with rather square 20 (40) Mhz channels with practically no energy outside [3].

Yet, everybody's stuck with 1,6,11 channel scheme which is wasting precious bandwidth. [4] (middle graph) Notice gaps between the channels that could be eliminated by moving 6->5 and 11->9, and gap on the right where channel 13 can fit after that.

[1] https://villagetelco.org/2009/11/rf-hacking/

[2] http://ecee.colorado.edu/~ecen4242/wlanb/index_files/image02...

[3] http://rfmw.em.keysight.com/rfcomms/n4010a/n4010aWLAN/online...

[4] https://www.codify.com/wp-content/uploads/2009/07/Central-Ro...

No need for modprobe on a system with sane udev: Just sysctl should be sufficient.

Indeed. systemd does boast respectable boot times (not as fast as hand-crafted shell script, but pretty good for a generic init).

On the other hand, error handling is pretty awful, especially during shutdown: Every now and then systemd would decide to give that one unresponsive sshd process a generous couple of minutes to shut down. Or will wait for a random filesystem to unmount itself for another 90 seconds. Sometimes outgoing systemd will lock up completely, until you do the magic ritual of pressing ctrl+alt+del 7 times within 2 seconds all while spinning around on your toes trice counter-clockwise and barking - to force "immediate" restart. Better yet - on special occasions this ritual devolves into farce: _after_ hammering ctrl+alt+del at machine gun rate it will print "rebooting now" and... lock up again. Until you hammer ctrl+alt+del again - only to see another empty "rebooting now" promise. SysRq would - of course - have no problem at all remounting filesystems ro and rebooting from this sad limbo.

Mostly minor things nowadays. I've seen so far:

- a while ago pa got audio routing wrong on a new/obscure laptop, wrong audio routing as in - speakers would not turn off if you plug in headphones. That eventually got fixed with dnf upgrade and no effort on my part;

- on ultrabook, pa sucks noticeable amount of battery by waking up 100 times a second (while no audio is being played). Something akin to what this poor chap is describing:

https://www.reddit.com/r/Fedora/comments/6d7776/pulseaudio_b...

Very much this. The only big change with pa in last few years is - applications accepted and embraced it - to the point of dropping OSS & ALSA.

This will attempt to open a child shell process with whatever output of "yes" is, interpreted as shell script.

But before that, parent shell has to buffer until EOF. With "yes" output being unbound, this means unbound buffering / memory growth. That is, until OOM killer take notice and shut it down.

Whole thing will probably take few seconds to a minute (depending on how much free RAM there is vs. how fast it is), peg a single CPU core in the process, and will recover cleanly (except for shell in question being terminated).

...unless system in question has single CPU and large+slow swap. Then yes, bring-it-to-its-knees.

What sort of payload throughput (in bit/s) can you get out of this, in a pinch?

...which (surprisingly) is a measurable amount. About 1 ms for `dash` and a whooping 9.5 ms for `bash` on a relatively slow CPU:

  pi@pi:~ $ time (for x in {1..1000}; do time echo | sleep 0.01; done 2>/dev/null)
  real    0m24.173s

  pi@pi:~ $ time (for x in {1..1000}; do time sh -c 'echo | sleep 0.01'; done 2>/dev/null)
  real    0m25.170s

  pi@pi:~ $ time (for x in {1..1000}; do time bash -c 'echo | sleep 0.01'; done 2>/dev/null)
  real    0m33.643s

> under way too much pressure to change phase from solid to liquid.

Nope. 90 bar is way too little for that. You'll need to crank up pressure to ~70 kilobar to get solid tin a at 460'C (733'K). [1]

[1] https://commons.wikimedia.org/wiki/File:Phase_diagram_of_tin...

There is a purpose-designed Chinese chip exactly for your situation - control brightness of a LED strip based on PWM input. Compared to a bare MOSFET, this chip gives you higher efficiency, current-controlled (i.e. flicker-free) output and ability to drive LEDs directly (without current-limiting resistors).

PT4115, pretty cheap on ebay and other usual places.

Yep. It is indeed easy to ruin a FET with minuscule amount of static charge. That is, unless there is a zener (or two, back-to-back) connecting gate to source. Many modern FETs have this built right in. E.g. ATP214 [1].

[1] http://www.onsemi.com/pub/Collateral/ENA1712-D.PDF

As floatboth pointed out above, it is possible to use a shell script [1] to dynamically change terminal colour mapping. Add this as "LocalCommand" to appropriate "Host staging-foo" and "Host production-bar" sections of the ~/.ssh/config file, and you're all set.

[1] https://github.com/chriskempson/base16-shell

OP is understandably upset about seccomp filters not being portable between different distributions and architectures. Fair enough.

But there's another glaring issue here. This app's seccom filter was written by a fairly security-conscious developer, who goes as far as saying he'd ideally want to reproduce any bug reports involving filter changes, and have serious unease accepting patches with new "allow" statements blindly. In other words, we can consider this seccomp filter to be as good as it gets, or close. And yet, this filter allows[1]:

- Full network access (socket/connect/bind/recvfrom/sendto);

- Full local file-system access (open/read/write/close/mmap/unlink/rename);

- Access to a long-time vulnerable system call that was only fixed relatively recently, i.e. probably fix still isn't applied on quite a number of systems out there (madvise) [2].

That's plenty of rope, if you ask me. How one could argue that process having all of permissions above is "sandboxed" in any meaningful way?

[1] https://github.com/kristapsdz/acme-client-portable/blob/mast...

[2] https://news.ycombinator.com/item?id=12756006

This.

Also, one should keep in mind that having to apply personal patches is perfectly acceptable for suckless software. In fact, for the very same st, to change font, colour scheme, or hotkeys/shortcuts - one has to edit config.h file and recompile. There is no traditional text config file or "Preferences" menu.

This might sound bizarre at first, but actually works as well as editing a text config file: config.h is very well structured and compilation only takes fraction of a second. Better yet, you're not constrained by opinions of previous commiters on what should be configurable and what - not. Which is the whole point, actually.

> don't have a sense of scale

From [1], complete db is ~300GB and from some iffy pixel measurement of the graph at the very bottom of that page, copying speed between otherwise idle db hosts was about 22.8 GB/hour (in-production replication is probably slower than that).

From that, 4GB of replication lag would represent 1.3% of db by size, or 10+ minutes of lag (as measured by time required to catch up under ideal circumstances).

[1] https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-...

It's both:

Title 47 - Telecommunication. § 15.5 (b) [...] subject to the conditions that no harmful interference is caused and that interference must be accepted [...]

https://www.gpo.gov/fdsys/pkg/CFR-2015-title47-vol1/xml/CFR-...

Biggest problem with large spindle is that noise and heat dissipation (both mostly due to air friction) are roughly proportional to the square of linear speed of the outer part of the platter, and bigger the platter, more linear speed you'll get at the same angular speed. On the other hand, you want to crank up angular speed to get any decent random IO operation/second value.

Last 5.25" HDD I've seen was Quantum Bigfoot CY [1], (which happened to be half-height FWIW), and this thing was pretty noisy even at 3,600 RPM. Dividing this by 60 (seconds in one minute) gives you theoretical maximum of only 60 random IOPS. Not exactly stellar, and as far as I remember, that was substantially lower in practice.

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

Not the GP, but it looks like significant number of Android vulnerabilities [1] are local privilege escalation (as in: install an app from a questionable source, app use vulnerability to silently gain root, app siphons off your data and/or wrecks havoc on the phone).

Hefty fraction of local privilege escalation vulnerabilities are in the Linux kernel, and pretty much every single Android device out there ships with its own, unique, outdated out-of-tree kernel with dependencies on a number of version-specific binary-only blobs. End result of all that is - even if underlying vulnerability is fixed in mainline kernel, phone's vendor still needs to repeat this exercise for each and every phone. Moreover, because of binary blobs, phone vendor oftentimes has to contact their SoC vendor, SoC vendor has to contact the vendor for that IP block they've shipped binary blob for, etc... All this process is extremely fragile, costly, and lengthy. Not exactly something you want to have in place for security updates. Google somehow manages to do half-decent job updating their Nexus/Pixel phones for few years after hardware hitting the market. Most other vendors drop the ball to some degree here, often completely.

Replicant took on a Sisyphean task of enabling blob-free (a.k.a. 100% free and open-source) firmware to some Android devices. Among other things, this could eventually enable one to use mainline kernel and do security updates much more quickly and efficiently.

Current status however is far from that ideal. Latest "stable" Replicant (4.2) uses various versions of 5-year-old kernel 3.0.x branch [2,3], and didn't achieve fully blob-free status either. That said, you can run blob-free, as long as you can do without 3D, WiFi, bluetooth, hardware-accelerated video and (depending on the hardware) without camera, GPS and NFC too [4].

[1] https://www.cvedetails.com/vulnerability-list/vendor_id-1224...

[2] https://git.replicant.us/replicant/kernel_samsung_smdk4412/b...

[3] https://git.replicant.us/replicant/kernel_samsung_espresso10...

[4] http://redmine.replicant.us/projects/replicant/wiki/Replican...

Pretty much all WiFi transceivers are indeed power-intensive, but it is actually receiving that often takes more juice.

ESP8266 consumes ~70mA with both CPU and WiFi running but idle, and 15mA with CPU idling and WiFi powered down [1]. That's 55mA or (@3.3v) ~180mW for _idle_ (i.e. receiving) WiFi circuitry. Again - that's WiFi only, with exactly zero RF power transmitted.

Now transmit. EU restricts amount of RF power radiated by a WiFi station/AP to 100mW. In US and few other places you can go slightly higher, but then other challenges arise, so for practical purpose most WiFi chipsets top out at 100 mW (a.k.a. 20dBm). Assuming RF power amplifier has efficiency of 32% [2], transmit duty cycle of 50% (that's transmitting half of the time and receiving for another half - pretty intense traffic here), we get:

(100/32%)*50% = just 156mW consumed towards "blasting out" some RF.

Clearly, receiving WiFi takes more. And there is a good reason for that. Most modern designs implement Rx as: Low-noise amplifier with some bandpass filtering -> Zero-IF mixer -> quadrature ADC -> DSP. It's the latter that does FFT, I/Q constellation tracking, demodulation, forward error correction, etc. essentially in software. And that takes a lot of power.

[1] http://bbs.espressif.com/viewtopic.php?t=133

[2] http://ww1.microchip.com/downloads/en/DeviceDoc/75003C.pdf

A bit of trivia:

- Each MLC cell actually holds one of 4 distinct charge levels, and thus can encode 2 bits. Same for TLC (8 levels, 3 bits) and QLC (16 charge levels to encode 4 bits).

- "3D" when talking about solid-state memory, would usually refer to vertically stacked cells [1], which gives you more cells per square millimeter at the same manufacturing process node. This is orthogonal to xLC.

[1] http://www.theregister.co.uk/2013/07/23/sandisk_takes_the_bi...

If you prefer an open-source and cloud-free solution, try VNC server + kanaka's VNC-to-HTML5 proxy:

  apt-get -y update
  apt-get -y install x11vnc build-essential
  git clone https://github.com/kanaka/noVNC
  x11vnc -quiet -viewonly -localhost -display :0 -scale 2/3 -ncache 10 &
  ./noVNC/utils/launch.sh --listen 8080 --vnc 127.0.0.1:5900

Last command will print an HTTP URL to share with viewers, which should "just work" assuming your viewers are on the same LAN/VPN and your computer has a well-configured hostname. Otherwise, extra manual step to set up NAT or port forwarding (+ adjusting URL appropriately) would be required.

Or, for sharing text-console only, just use tmux.

You don't even need a jail for that. Just add those lines to the end of /etc/ssh/sshd_config:

  Match User pi
        AcceptEnv
        ForceCommand echo 'To enable SSH, do this and that'

EDIT: added an explicit empty "AcceptEnv".

Interestingly, there seem to be an established names for flat/planar/2D inclusions:

https://en.wikipedia.org/wiki/Intercalation_(chemistry)

As well as for point/0D inclusions:

https://en.wikipedia.org/wiki/Clathrate_compound

..but not for what this article describes, which appear to be linear/1D inclusions.

That is not quite the same thing. Andy's NVMe patches allow drive itself to go into deeper power-saving states, while discussion above was about power-management of SATA controller which is part of PCH (earlier known as northbridge), which in turn, on last 3 generations of Intel CPUs is integrated into the same die as CPU itself.

Unpleasant side-effect of SATA (or NVMe) controller being integrated onto the CPU die is that it now shares a power domain with the rest of the chip (i.e. PM being present or absent on SATA controller affects allowed set of C-states for the whole package). In other words, as long as SATA controller don't go into deep sleep (i.e. never - without power management enabled), whole CPU+PCH package would not go to deeper C-state. Thus, lack of PM in storage controller has disproportionately high effect on the total system power consumption.

That is a very good point. I would go even further and say that Canonical, too, shouldn't have to apply patches. That's upstream kernel's job.

But here's the rub - on some hardware enabling SATA PM can sometimes lead to various weird bugs - from failure to boot to crash with blank screen after few hours of working perfectly. And Intel would't release any sort of documentation that sheds any light on why that is the case, and what should be done to avoid it. Intel does know what to do, since (sic) Intel's storage drivers do the right thing on Windows.

Which brings us to even stranger point: Intel apparently doesn't share this documentation with Microsoft either. Hence new laptops with pre-installed Windows ship with Intel's storage drivers, while installing vanilla Windows 10 with Microsoft's storage drivers will give you as bad a battery life, as you get under Linux. This is an issue important enough that some laptop vendors employ hardware tricks to make storage hardware "invisible" for normal Microsoft's drivers for no good purpose other than to enable Intel's driver take over this hardware smoothly. See for example recent "Lenovo fake RAID" debacle:

http://mjg59.dreamwidth.org/44694.html

Regarding 13h vs 22h battery life - I wonder if c't did any test with manually enabled SATA power management? This is a big deal on recent Intel hardware and unfortunately is still not enabled automatically by linux kernel, as described here:

http://mjg59.dreamwidth.org/42156.html

Easiest way to enable this is to run "powertop", switch to "Tunables" tab, then toggle all lines that look like this:

  >> Bad Enable SATA link power management for host0
  >> Bad Enable SATA link power management for host1

Some chromebooks have aarch64 ARM CPU, including new Acer Chromebook R13

There are plenty of apps for that already. My favorite:

http://wkhtmltopdf.org/

Truly impressive overall. Unfortunately, it looks like training set was way too small. Look for example at reconstruction of #13 here:

https://phillipi.github.io/pix2pix/images/index_facades2_los...

Notice white triangles (image crop artifacts) present on the original image, yet completely absent on the net input image. They make re-appearance on the output of 3 (4 even?) out of 5 nets despite the lack of corresponding cue in the input image. Looks like network cheated a bit here, i.e. took advantage of small set size and memorized the input image as a whole. Then recognized and recalled this very image (already seen during training) rather than actually reconstructing it purely from the input.

Same (but less prominent) for other images where "ground truth" image was cropped.