Recently posted comments

Indeed. Judging by a handful of European developers whose time zones I know, about half their commits to 5.0 are in DST, and if they're in any way representative, a significant portion of the results are tilted one time zone to East.

I'm not 100% sure you're correct there:

https://gdpr-info.eu/art-17-gdpr/

> The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay [...]

That applies to all data controllers, where a controller is:

https://gdpr-info.eu/art-4-gdpr/

> ‘controller’ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law;

So, if you "determine the purpose and means of the processing of personal data" - i.e. you have personal data about a "data subject" - a person, then that person has the right to request that data be erased, according to various criteria.

Note that that appears to apply to *all* data controllers, not "only search engines and indexes".

So if you post your address to a social media platform, and then you decide you don't want them to have that data, you should be able to file a GDPR erasure request to get them to delete the post.

However, I'm not sure how that works with a distributed system like git. If someone asks me to delete a git commit that has their personal information in it, that could be tricky. I think some people who were looking at different ways to add large file support came up with an idea to be able to tell git "hey, there should be a blob with hash #xxxxxx here, but it isn't here, just ignore it" - without it throwing a fit, so you could delete stuff without invalidating history. Or you could just delete the whole git tree, which would fulfill the erasure request too. But having fulfilled the erasure request, if you clone/pull from another user who did not get the erasure request, and get a fresh copy of the data - is that then OK?

If the former, how do you imagine that financial / banking institutions lend more gold than they physically possess?

Something that the GDPR's detractors repeatedly "forget" - the GDPR does NOT NOT NOT apply to original material. It only applies to search engines and indexes.

So anything I post about me is not covered.

And anything I post that is defamatory / libellous / slanderous / whatever about someone else is already covered by other laws.

Americans seem to have this weird idea that everyone else's business is something they have a right to be interested in, and that no-one has a right to a protective wall where they can say "keep out".

The GDPR simply says that I have an interest in information about me, and I have the right to a say in how it is used. ESPECIALLY if it wasn't me that handed over the data in the first place - facebook, I'm looking at you !!!

Cheers,
Wol

This has actually been confirmed by fMRI scans: expensive wines taste better. Objectively – because those parts of your brain that are responsible for enjoying stuff are more active. The fact that this effect is caused by the price tag instead of the actual fermented grapes is of secondary import.

Isn't it a general thing with entering a market that it makes sense to find an underserved niche which is not very interesting to the incumbent players?

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

http://www.cpaptalk.com/viewtopic/t174687/SleepyHead-Proj...

Or is this just another example of the monster cable effect, where folks justify ridiculous levels of cost & time investment with empirically-false claims of superior results?

But from the description of gitgeist, I don't see why that'd be a problem for it. It sounds like every user has their own independent git repository, they refer to other users by repository URL, and posts are represented by directories and files. None of it intentionally depends on commit hashes, so rewriting history should be fine: you can delete stuff from your own repository and continue participating in the network as normal, and if someone else has a cached copy of your now-deleted commits then that's not your problem. It doesn't seem to be depending on any unique properties of git, it's just using git as a database and as a data synchronisation protocol, so it's basically the same as if you used any other kind of database.

SSH supports CAs in addition to the baseline Trust On First Use system most people experience. The baseline lacks any meaningful authentication for the first connection to a server unless a fingerprint / key is communicated out-of-band. It also does still include a lot of bad cipher options, and included more in the past. HTTPS only looks bad if you're talking about the legacy protocols, which aren't necessary in other contexts like they are for a browser. You can stick to TLS 1.2 / 1.3 only elsewhere.

- Does the matrix allow you to search users globally? I really think that one of the reasons for the success of things like skype or facebook is the fact that you can rapidly build your own network of people to communicate with by searching them (with them only accepting being searched). Without global searches, someone must first tell you how to find him/her.

- Do you need to configure the connection to a turn server in order to be able to use it from natted connections or is nat traversal autoconfigured (as it is in skype, whatsapp, etc)? For instance, one of the issues with ring/jami is that (at least in my experience) it cannot be used reliably on machines that are moving around like laptops/mobile phones as way to often you get an internet connection from which the application stops working.

That should surely be possible for a distro that wants to do unusual things and only costs an extra exec() for starting up scripts which aren't known to be that fast anyway.

https://signal.org/blog/license-update/

It gets down to the most fundamental characteristic of inter-human communication: the fact that *all* human languages are programming languages because human language is the effort of one person to program others' neural nets to think her thoughts. Some day I'll challenge all software people to master English (or at least master their native languages). The internet is rife with examples of ambiguous human programs. Shoot, a reading of NHRA's carefully-prepared rule book will reveal lots of ambiguities; some rule is intended to prevent injury A, so the racer must do Q but the rule, as written, allows lesser X, Y, and Z actions as well. (As much as I try to write clear English, I often still fail to communicate my thoughts to others; I'm sure this missive will be no exception.)

The BeyondCorp security model was mentioned, in that it opened one's private internetwork to the universe. Something that isn't quite as bad is TLS because it bypasses the private internetwork's perimeter firewall. Once the encrypted link it established, the firewall cannot block malware or theft. IMO, the time of SSL/TLS is long past and it should be largely retired; the recent push to shove TLS everywhere is misguided at best. The proper solution is host-to-gateway and gateway-to-gateway opportunistic encryption. Prevent deliberate, casual or incidental observation of private/confidential data, but allow perimeter firewalls to block trojans, viruses, ransomware, phishing, data theft, and other 'crimes'. (People who are terrified that someone might see what they're doing on an internetwork probably shouldn't be using the net in the first place. IMO.) VPNs must be allowed, but all network traffic other than the VPN should be forced through the business/SOHO/personal firewall so that it can be filtered and inspected for malware. Most people don't use VPNs because most software engineers and programmers make it too hard to use.

Basically, I generally agree with Miss Chen. Usability and security must go hand-in-hand. Engineers, programmers and coders nede to learn to think like ordinary people; they need to crawl out of their virtual universes and learn to communicate with non-technical people. And non-technical people need to learn some of the tech terminology so they can more readily learn how to best use the tech they own. Many smart phones have multi-GiB RAM because people don't know or don't care that they have 500 apps open. When I finish using an app on my phone, I close it; I think the most apps I ever had open at one time was 8. When I need the net, I turn WiFi or cell data on. When done, I turn them off.

I mean, this is potentially not a risk if there is a recognizable way of communicating low-bandwidth fingerprints of the next encryption level, like ZRTP verification on voice. But note how WebRTC has done the same thing? And efforts to solve the problem are talked about and then, somehow, nothing ever happens with the standards.

It's enough to drive one paranoid.

Linux's Traffic Control is poorly documented and leads to impossible expectations. I designed a nice JS-based configuration tool that I eventually abandoned because LTC just cannot do what the documentation says. However, once I really understood what it can do and what it cannot do, I was able to 'fix' traffic control so that, for the most part, traffic flows smoothly. LTC also cannot easily control multiple interfaces; for example, a gigE NIC might be able to 'block out' a 100Mb/s NIC when they both 'send' to a 10Mb/s internet link.

I haven't addressed buffer bloat. 'ls -lstr /' through an SSH connection results in ^C being unresponsive for 5-10 seconds. But dealing with that much output doesn't happen too often.

In short, there *are* Linux-based routers that do a nice job of enforcing bandwidth sharing. And some of them are free.

Also not a lawyer. :)

port to linux 4.15

It's a sad story, in any case. Unfortunately, it's not limited to software (open or not); I've seen very similar abusive entitlement from readers against science fiction authors when the next book in a series is delayed.

Fixes: NOTHING - don't ever back-port this to stable

E.g., with bash, if execve fails with -ENOEXEC, it will reset all the shell state and evaluate the #!-less script file directly in the post-fork bash process, rather than exec'ing anything at all (neither /bin/sh nor /bin/bash!)

The part I disagree with is the "all of your friends". This wouldn't be something I want all my friends to be on. This would be more something I would like to be a more technical network, where I would want to save all the posts and what was discussed, on my personal harddrives.

Thus, if you get a few people to start posting things that others would like to have access to, then it can be a success, without having "all your friends" being on it. And it being decentralized and open source, it would work with 10 people using it, or 10,000,000 people using it.

In any case, since I'm interesting in doing much the same thing, porting Krita to iOS and Android, I'll take a look at how subsurface has set things up. What I'm wondering is, how many dependencies does subsurface have...

Of course, Krita has a _huge_ ui layer, all QWidgets, and our previous QML ui broke when Qt moved to a scenegraph for QML, so our OpengGL canvas broke. And a huge number of dependencies, as well.

There was a lot of hallway discussion afterward. Also, we discussed it some at the speakers' dinner for the track. There was a very lively debate there. :)

I realize there was none of this available to you; next time someone from LWN is at our Legal & Policy DevRoom, please do let us know. I can't promise the press will be invited to the speakers' dinner, but I would have made the case that you should be invited to the DevRoom co-organizers.

(I co-organize the DevRoom where this talk occurred, along with Tom Marble, Karen Sandler and Richard Fontana.)

The main problem is, however, that these needs are not a well-defined deliverable that'd be easy to organize some funding around, crowd- or otherwise.

In fairness, I should note that as soon as Lindberg read the article, he asked for a short note about the Q&A to be added. I declined, so the article as published rather skates over the Q&A, as you note; if I'd added a para about it, I would have said something like this (and I'm grateful to Lindberg for certain elements of this summary):

The Q&A period was short. The only probing legal questions that were asked related to design patents (Lindberg replied that he'd not done the analysis) and to Bowman v. Monsanto. That case was about patented seeds, and whether the creation of new seeds was covered by patent exhaustion; the Bowman court held that the patent right to make a new copy wasn't exhausted by the sale of the seeds. Lindberg argued that the difference was that that the Monsanto licence agreement forbade anyone from replanting seeds, where FOSS licences grant the rights to copy and make.

> a lot of the folks in the room felt that his argument might be sophistry

That may well be true, but I fear I missed the straw poll whereby it was established.

> I suspect his exhaustion theory would need to be adjudicated before we could rely on it heavily in FOSS.

That, I would agree with.

https://www.in-ulm.de/~mascheck/various/shebang/

I note the wink, but others might not realize that OIN membership doesn't do much for FLOSS generally as the Linux system definition is quite narrow and OIN is (not surprisingly) not open to including key FLOSS projects that implement technologies where OIN's members and funders have heavy patenting.

As for Van's talk, definitely listen to the Q&A. Van is a very engaging speaker but a lot of the folks in the room felt that his argument might be sophistry. I really hope Van's arguments in this particular talk are right, but they appear to be pretty radical views among patent attorneys. I suspect his exhaustion theory would need to be adjudicated before we could rely on it heavily in FOSS.

If the "stable" kernels are going to have not-manually-selected/verified changes in them, and a shorter release cycle, it seems to me they'd increasingly become "alternative bleeding edge" kernels with older features, but "assorted newer patches added in for flavour." At which point I wonder who would run them? Those wanting actual stability probably end up relying on their distro kernel teams manual review, and those wanting the bleeding edge probably want the new features too. In other words the explicit manual selection of "stable" changes, and the QA, is what makes them "stable" kernels. Which seems increasingly not to be happening with the upstream kernel stable trees, because it's a lot of work.

As a sysadmin my desire for "stable" anything is (almost) no regressions, and some fixes for critical issues. Almost by definition with a preference for stability (ie, availability/reliability) over changes.

Ewen

you can. the ability of out-of-order instructions to be delayed (stopping them from writing to the register file) permits them to also be cancelled entirely.

the combined ability of cancellation and prevention of commit is what permits speculation and branch prediction, as well as something called "precise exceptions" to be added. none of those features *have* to be added, they are each separately and individually optional: they just happen to be based on the same fundamentals.

It's not a matter of either/or. Programs should be both portable *and* useful.

> A user can expect that qsort sorts, but can they expect that it does so reasonably quickly? How often can you call fsync to maintain a reasonable balance between speed and safety? That's never going to be defined by the standard...

Why not? Standards do sometimes specify things like algorithmic complexity. C doesn't specify that for qsort(), unfortunately, but C++ does require std::sort() to be O(n log n) in the number of comparisons. What constitutes a "reasonable balance" is up to the user, but there is no reason in principle why there couldn't be a standard for "filesystems useable with PostgreSQL" which defines similar timing requirements for fsync().

I know more users of dedicated mail clients than users of web-mail, even within the subgroup of plain normal computer users.

Maybe it has something to do with age. With a mail client you are not subjected to permanent change of UI and can use your capacity for learning to something of intrinsic value. The reluctance to cope with often relearning how to use a *tool* seems increasing with the shortening of the remaining span of life.

That's... kind of insane. Is this point of view common? That might explain all the scripts I see written by devs (often java devs, but not always) that are kept chmod 644 and have no shebang.

The first thing I do is make them executable and put the proper shebang in, unless there's some specific external $PATH call I need to wrap into it, which is just dumb... or weird.

This actually feels like a decent shibboleth among *nix admins and... non-*nix developers.

That's what corbet said but it's not exactly what's happening - if you look at the patch there's no default to a shell, it just returns an error that the file was not executable.

The shell is the one that takes this "can't execute" error as a cue to interpret the file shell instead :-x

>By default, the interpreter is a shell, which will interpret the file as a shell script

is not really correct; it's a shell convention but the kernel will definitely _not_ use a default interpreter if the file does not start with #!

I was somewhat familiar with patent exhaustion, but I definitely was not this well-informed about it.

Well, only a single argument, not "arguments".

#! /nix/store/mbwav8kz8b3y471wjsybgzw84mrh4js9-perl-5.28.1/bin/perl
use lib qw(
/nix/store/x6yyav38jgr924nkna62q3pkp0dgmzlx-perl5.28.1-File-Slurp-9999.25/lib/perl5/site_perl
/nix/store/ha8v67sl8dac92r9z07vzr4gv1y9nwqz-perl5.28.1-Net-DBus-1.1.0/lib/perl5/site_perl
/nix/store/dcrkvnjmwh69ljsvpbdjjdnqgwx90a9d-perl5.28.1-XML-Parser-2.44/lib/perl5/site_perl
/nix/store/rmji88k2zz7h4zg97385bygcydrf2q8h-perl5.28.1-XML-Twig-3.52/lib/perl5/site_perl
);

possibly adjusted to deal with the subtle differences between BEGIN { unshift(@INC, 'foo' }, use lib qw(foo), and -Ifoo--I remember there are some, but I don't remember what they are.

IIRC Perl 4 doesn't have 'use' or 'BEGIN', so perl4 definitely needs the shebang hack...but perl4 also implements a lot of bizarre stuff like "execute perl embedded in non-MIME-encoded email message", and...not the shebang hack (or at least it's not documented). Perl4 and NixOS are separated by a decade, so I doubt perl4's limitations had much to do with NixOS's design; however, early-2000's bugs in the Perl5 implementation could have been a problem for a project starting in 2003 (I know it was a problem with several of mine!).

Anyway, the answer I was looking for is apparently "only Perl and Guile do that, and NixOS does it for historical reasons, and they're going to stop now."

I, for one, would prefer to solve that problem.

i.e. have a namespace that I can reference from portable scripts, like "#!/prefix/org/python/python/2.7.5", where the python installation puts in as many symlinks as required to accurately state the level of backward compatibility achieved.

[*] Eg, starting with perl 5.16, xs functions can't be loaded via Dynaloader anymore unless a new keyword is added to the existing code. The documentation makes it very clear that loading xs-functions via Dynaloader Is Just Wrong[tm], but there's no positive justification for the change.