https://www.youtube.com/playlist?list=PLVcHxw2MHN0SCgxkqsQUg... is a pretty good selection of traditional greenwood skills. The shingles videos contain a fair bit of the riving as described in the article.
2,735 karma · joined August 29, 2009
In emacs esc-esc-esc is something I use relatively often.
It gets even worse over slow ssh to somewhere remote, when visual state updates could take up to several seconds.
On other keyboards I'd assume the tactile click of the key was a press, and could chain up extra inputs. Now I much more often have to pause to check I did in fact trigger the esc at the right point.
The other annoyance is the lack of touch force means even a slight overshoot on the number keys or ¬ will probably also trigger an escape, so I have to keep that it mind. It's much harder to do with a physical key because it takes more than brushing it with a fingertip when using the finger pad to press the targeted key.
Better haptics might make the touchbar a bit less obnoxious (and Better-Touch-Tool can already trigger the trackpad 'click' when a button is touched, but isn't ideal)
If Apple can implement 'force touch' on the trackpad, I suspect it could be possible on the bar as well, so it needs to be "pressed" rather than just "touched".
Here's[0] is my previous MBP. Pressing anywhere on the escape key will trigger a keypress. You don't have to be perfectly centred on it, and even having a finger half-off the left side will work.
Does that work for the non-visible bit of the touchbar?
And how do you know when you've actually pressed it, if the app doesn't immediately indicate it, and you're not looking down at the "button"?
[0] https://cnet4.cbsistatic.com/img/27By8ZzhyWJoIxipAsZsz3W0bj8...
I'll have to poke around with feedbase and see what you're up to. My (probably badly though-out) idea was a somewhat generic server / API adapter that could be hooked up to make less terrible interfaces for something like HN or reddit, similar to how bitlbee does IM <-> IRC.
Trips passing floors 3, 7, or any floor in which any resident has recently taken a shower, may revert this Fully Autonomous Lifting Device to human operated mode immediately following a n assertive audio tone. Failure to correctly operate the pop-up controls during this unlikely occurrence may result in death or serious injury to you and any other passengers. Please take the time to familiarise yourself with all operating controls that will rarely if ever be required."
There's at least 2-3mm of dead space on the LHS of the bar.
Do you have any recommendations for server-side software/libraries, or docs beyond the original RFCs? I've idly contemplated various uses in the past, but never really fully understood how the various bits would go together.
Preferably not the one shown here[1]
I haven't yet found a replacement, although I haven't been looking very hard recently.
Roughly telephone-equivalent bitrate is <100kbps, potentially down to 8kbps or so for (bad) speech.
Noise-gating or even rudimentary voice detection (sound is a voice, not random ambient) can reduce that duty cycle to a tiny fraction.
So you could get a lot of useful information out for <100MB/day.
If you wanted to be sneaky, there are probably viable ways of hiding it from casual detection; buffering locally and appending to user-uploads (images, video, voice) when there's already data flowing.
Or do some pre-processing on the device to slim it down even more. Maybe only when it's on external charge to avoid running the battery down too far.
I'm not suggesting this is actually happening, but it's far more plausible than your estimates suggest.
The ArchiveTeam[1] have a simple VM image that anyone can use to schedule and coordinate large site archival jobs that might already address some of teh issues.
Might be tricky to find people willing to provide resources, but with even a smallish group it might work out. May need to consider abuse and run multiple queries and compare results, which might add to the overall request cost.
Depending on how quickly regulators can act, and how they would determine the date of precedence for 'the preceeding financial year', it's just about conceivable that a company might have >1 year of warning to do some financial trickery to minimise their fines.
Having a range(0..max($turnover_amount, $fixed_amount)) reduces the scope for that sort of trickery.
I'd hope there would be some opportunity for caching to make it a bit cheaper than every single request, but maybe with dynamic targeted or real-time ad bidding that wouldn't work so well.
Isn't video advertising mostly handled at a higher layer by sticking some segments into the playlist/container rather than actually encoding it into a single video unit anyway?
How do you access data that's held about you by/in Google Analytics, anyway?
Member States shall by law reconcile the right to the protection of personal data pursuant to this Regulation with the right to freedom of expression and information, including processing for journalistic purposes and the purposes of academic, artistic or literary expression.[1]
Not sure how that's 'complete freedom to ignore' exactly, nor is that an exhaustive list, just some examples of where they may need to be balanced against other freedoms.
Right now to compete with Google on 'free', their existing search, browser, mobile & advertising operations make it massively difficult for others to compete and extract similar value from users.
But if that's not allowed, and the practical business models involve charging users directly, it might be possible for small businesses to offer enticing services at comparable prices.
If a national data regulator was pushing ahead with £xxM fines your objection might have some merit.
This seems (based on my complete lack of knowledge of the specific facts the cases are arguing) more like patent-trolling or general settlement-shakedowns than organised governmental abuse of powers.
https://en.wikipedia.org/wiki/The_Jungle
Consider how many modern food standards regulations came about, and what abuses they were addressing.
That is, if you're offering such a service that exploits users for their data, then I would never want to use it, so it might as well be blocked, for all I care.
Maybe even desirable if it was, so you don't come across it by mistake and sign up without doing proper diligence.
Freedom of choice is nice, but there's an argument that putting rat-poison in food products isn't ok, even if you label it on the package.
I mostly agree that the lack of concrete measures makes it horrible from a compliance view, but I'm not sure you can have both things, especially in a relatively immature area of law.
Arguably much or all of the entries with FKs to those rows as well, transitively. Unless you don't believe in normalisation :)
I would expect that to be a fairly common sentiment/belief (though I might be wrong).
It comes down to the particular definition of 'unreasonably' that is being used, which different groups can and do disagree about.
So yes, they can if they choose, and if they can make a convincing case, and you can't make an appeal or a big enough media shitstorm that they back down.
But is it likely?
Are you equally worried that you might die tomorrow because a meteorite crashes into your house?
It could happen, and the consequences would be pretty massive, but it's not generally a serious concern of most people.
Risk is likelihood x harm, and you're seemingly in every thread shouting about the massive potential harm, without ever really considering the likelihoods.
Exactly how likely it is I don't know, but I highly doubt it'll be close to your expectations. And probably not mine, but maybe somewhere in the middle.
A web access-log records (ts, ip, request, ...), or maybe your application log stores (ts, ip, action, params, ...)
So the information from that single source is "at time T, IP accessed RESOURCE".
It's possible that's personally identifiable in context (if you have additional controls that RESOURCE can only be accessed by exactly 1 real person, etc)
But say it's not. All you know is: Opaque PERSON accessed RESOURCE.
if you can obtain the identifying information from elsewhere (buy, steal, etc) from ISP or whatever, you now know that (T, IP) = NAMEDPERSON.
A simple lookup/matching means you know that NAMEDPERSON accessed RESOURCE. That's the new personal data.
The IP isn't irrelevant, because without it, you'd have no lookup key to determine the mapping from PERSON? to NAMEDPERSON.
I suspect it's sufficiently ingrained in existing apps to make it hard to deprecate completely, but something like the path stripping might be a decent compromise.
For cross-origin requests I think there's also a mandatory 'Origin:' header that would identify at least the domain (but not path) a user request was referenced from.
I used to use a firefox addon called RefControl but IIRC it was a casualty of the quantum/webextensions transition. uMatrix has a basic referer spoofing capability, but it's all or nothing for a particular site/scope.
Consider: You're CompanyX, and I'm DodgyFontHost.tld My business model is exploiting and selling as much data as I can gather/mine from my traffic.
You embed (that is, reference/hotlink) some of my fonts on your pages.
If a user visits your page, and as a result makes a request to me for a font, I can log everything about that request, but I don't (afaik) have much/any additional knowledge that makes it particularly useful.
Assume there's no ?UTM=... tracking content in the url itself, you're just referencing a static font file.
I'm not sure offhand if browsers would be passing a referer header by default, or if that could somehow reliably identify the site I'm actually visiting. If so, that'd be one valuable fact.
I might be able to fingerprint the users browser from other headers or their OS from network-level quirks.
Anything else I'm missing?
I feel like 'IP $x made a request for $file' isn't the important thing to be looking at here, it's what I can learn from other things associated with the request that I can exploit.
But yes, if you had a reliable lookup from (ip,timestamp) to legal person, then it's absolutely Personally Identifiable.
Imagine if every browser set a valid, correct 'X-Requestors-Legal-Name: Bob Smith, Sometown, USA' header on every request. That's obviously identifiable. Adding a layer of indirection doesn't make it less so, although it does maybe place it on a continuum of 'cost/effort to identify based on this info'.
It ranges from 'trivial, because it's right there in the content you're sending', through 'not directly, but easily enough via subscriptions to one or more commercial data providers' to 'if someone steals our data and combines it with stolen data from several other sources, they have a non-zero chance of guessing your identity correctly'.
IIRC there are services along those lines for various 'contact your $REPRESENTATIVE' political and activism lines. I vaguely recall something about how the US has specific laws allowing certain requests to be ignored (or maybe even criminalising the sending of) generated or form-letters, due apparently to this sort of abuse.
Can't remember what the exact context was that I saw it, but it might have been FOI or something data- related