amboar

> Given the difficulty of cracking end-to-end encrypted messages during transmission, one option would be to improve warrant-based access to communications at the sender or receiver ends, Senator Brandis said.

> "At one point or more of that process, access to the encrypted communication is essential for intelligence and law enforcement," he said.

> "If there are encryption keys then those encryption keys have to be put at the disposal of the authorities."

The last part of the quote muddies the water a bit. Maybe they are interested in cooperation from companies with control of endpoint software (Apple, Google, Microsoft) to extract the keys?

devicetree is how this is all typically managed for Linux on ARM.

Australia recognises it does poorly in this regard: https://industry.gov.au/industry/IndustryInitiatives/Pages/B...

TimVideos is an open source project using FPGAs and Python for conference (and other) video capture: https://hdmi2usb.tv/home/

So if you're interested in hardware, FPGAs or Python, it's a great opportunity to get hacking! They are also part of GSoC this year, but it might be too late to apply.

There's more recent news on that front: https://blog.rackspace.com/the-latest-zaius-barreleye-g2-ope...

Having the initrd merged with the kernel is slightly less hassle when netbooting to test during kernel development

Another approach is to use Signal's "Linked Devices" capability. Designate a central "device" (server) for FOIA purposes, and mandate all relevant public servants/elected officials using Signal add that as a linked device.

Then there's no need to retrieve a device and dump its message store, which obviously depends on the device being in a functional state. Instead there's a one-time setup when Signal is first installed.

I think of this case as boring vs tedious. Tedious code should be refactored (if possible) to become boring.

Great! Thanks for taking the time to reply. Unresolved questions always bug me.

This is a shot in the dark but some nasty hibernation bugs are fixed in 4.8[1]. It's probably worth booting a kernel from that series to see if it helps.

[1] https://lwn.net/Articles/701639/

For bash or any other application using the readline library you can configure it for vi mode by adding 'set editing-mode vi' to your ~/.inputrc. Note for bash you can instead add 'set -o vi' to ~/.bashrc to avoid setting the mode for all readline applications

I don't know how recently you've played with pinmux on Linux, but my understanding is the pinctrl subsystem should handle runtime muxing without wetting the bed. What issues did you run into?

If your running relatively recent kernels on the board there's now a character device interface for gpios: https://patchwork.ozlabs.org/patch/580307/

> As you say, now you have two million-line codebases to understand instead of one :-)

Yes, I guess part of the problem is figuring out how much of that you (don't) need to know.

> I think there are things we (the QEMU community) could do to make the learning curve a bit less steep but it is still definitely there...

I found the reviews were clear and insightful: In my opinion that goes a long way to making it more approachable, though I guess only if you've got so far as having a patch to be reviewed. That said, even if you don't yet have a patch, reading feedback on relevant patches from others can be just as good.

> You say you had "emulated" hardware - what this means, exactly?

Software pretending it is hardware, for example QEMU: http://wiki.qemu.org/Main_Page

> Which kinds of drivers you have developed this way?

As an example, this approach helped me develop a pin-controller driver[1]. I first added a new bare-bones SoC and machine to QEMU[2] to give me enough of a environment to start adding other models, such as the SoC's System Control Unit[3], which in-turn contains the registers the pin-controller driver pokes at. Using QEMU I could control the initial values in the registers and exercise the pin controller driver's implementation.

> I guess it's not possible to test driver code unless probe() succeeds, which requires actual hardware to be in place.

Not entirely - if you are writing the driver you can always pretend it succeeds! Ideally you want to get some gratification as soon as possible - if that means making some assumptions and nasty hacks, that's fine (as long as it won't smoke something!) Then start iterating to iron them out. At least, that's the kind of approach that works for me.

[1] https://lkml.org/lkml/2016/7/20/69

[2] https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg...

[3] https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg070...

An approach that's worked well for me was to first hack qemu to add some new (emulated) hardware, then write the kernel drivers using qemu to test (followed by running on the hardware). That does leave you with two problems instead of one, but is quite flexible when you are trying to track down bugs and can increase your hack/compile/test velocity.

Well, there's the GPL-styled approach: anyone with access to the results must also have access to the associated data. This doesn't mean it is mandatory to make it public, though you'd have to restrict the redistribution freedom.

I maintain some Python scripts that graph my spending from CSV transaction exports: https://github.com/amboar/fpos/

It does a few nice things like automatically determining your recurring income and expense patterns, which allows it to do a bit of forecasting. I'm working on expanding that capability at the moment to summarise savings progress for recurring expenses with multi-month periods. Contributions welcome!

Package signing by the package's author /is/ the solution, right? This way the only entity that can publish a valid update is the the package author. This still has the problem of bootstrapping the trust relationship, and leaves the door open to the author publishing a malicious but signed package or the signing key being stolen and used to do the same. However if you don't trust the package author to be responsible or take precautions against the keys being stolen then you're essentially taking on the burden of implementing of your required functionality.

It was more that Tridge "reversed"[1] the Bitkeeper protocol, leading to licensing issues and the eventual separation of Linux from Bitkeeper. The need for a high performance, distributed replacement motivated Linus to write a git.

[1] https://lwn.net/Articles/132938/

Isn't it an indicator of success that it is the first result in almost every Google query? The articles don't write themselves and Google tries to show the most relevant information, hence the articles must have some standing before they percolate up the results.

Yeah, this is what I ended up doing. I maintain a little project[1] that parses the CSV files and graphs your spending habits as well.

I also wanted fuzzy string matching, but I ended up writing my own clusterer in C to get the speed I wanted, and then wrapped it up as a python module. Must admit I hadn't considered difflib. The c code now lives in ccan[2]. I've got a patch to add the string vector cosine measurement as a filter which gives quite a big performance boost. As a rough indicator, on my laptop it clusters 3500 transaction descriptions in about 600ms.

[1] https://github.com/amboar/fpos/

[2] http://ccodearchive.net/info/strgrp.html

Regarding -Werror, its considered by some to be bad practice for releases [1].

[1] https://blog.flameeyes.eu/2009/02/future-proof-your-code-don...

So at the bottom of the article the author points to bugzillas for GCC and LLVM, and points out that compilers actually do have bugs. It feels like an admission that the title is really just for attracting clicks, and that the first para of the article could've just been ignored or dropped.

Interesting; I might poke around at Ledger. Recently I just wanted to see what I was spending money on in a few simple graphs graphs, and so hacked together some python and matplotlib: https://github.com/amboar/fpos. fpos doesn't do anything complicated, but allowed me to see where my money was going without me doing too much tedious work.

I tried to make the title less link-bait-y, hopefully it's an improvement.

Fair enough! I'll keep that in mind :)

Yeah, I agree with your examples aside from the ability to validate XML; I'm not a heavy user of json but I don't believe it's possible to tell whether a document is well formed. Anyway, the lack of rational means it doesn't address essential vs accidental complexity. Are the harmful items harmful because they have lots of accidental complexity? Or are the problems they exist as a solution for simply hard problems? If complexity of a harmful entry is mostly essential it would be interesting to know why it was still considered harmful. For instance, Bash is considered harmful but is nice as a user shell compared with say, sh.

The table of harmful things and alternatives is fascinating. I'd love to see the rationale for each row.

No worries :) It was a genuine question though; I've done some brief googling in the past but didn't find anything authoritative.