Recently posted comments

Which I like to paraphrase as, "If all you have is Excel, everything looks like a spreadsheet."

As far as I can tell, Subsurface build target set is very similar to OpenOrienteering Mapper one.

https://github.com/OpenOrienteering/mapper/releases
https://github.com/OpenOrienteering/mapper/wiki/Target-sy...

Sounds terribly like web browsers of today. Not sure that replacing web apps with git apps would be such a bad thing. :)

> 5. Better to make a few users love you than a lot ambivalent.
>
> Ideally you want to make large numbers of users love you, but you
> can't expect to hit that right away. Initially you have to choose
> between satisfying all the needs of a subset of potential users,
> or satisfying a subset of the needs of all potential users. Take
> the first. It's easier to expand userwise than
> satisfactionwise. And perhaps more importantly, it's harder to
> lie to yourself. If you think you're 85% of the way to a great
> product, how do you know it's not 70%? Or 10%? Whereas it's easy
> to know how many users you have.

http://www.paulgraham.com/13sentences.html

The readahead system call does that.

In this passage :

"When CONFIG_HIGHMEM is not defined, is_highmem_idx() (and PageHighMem() derived from it) return zero unconditionally. Any code within functions that follows the "if (PageHighMem(page))" pattern will be automatically optimized away as dead code.

But this works only because is_highmem_idx() is marked static; ".

Why this works only for static functions ? Static keyword implies only about the internal linkage right?

Thanks

European legislation on the other hand, as someone else pointed out, is more interested in outcomes. So you should legislate that "businesses must be able to demonstrate robust, working procedures for dealing with the bugs in the code in their products". In other words, if your reaction to a bug report is to sweep it under the carpet, or if it's a serious bug to run around like a headless chicken, then you're in breach of the legislation and liable for the consequences.

If, on the other hand, you have a mechanism for creating, and rolling out, bugfixes to your products to deal with problems then it's much easier to show compliance with the legislation - you just point to your security team and say "watch them triage bugs, create fixes, and roll them out". The system is there, it can be watched in action, and while it may not (indeed, pretty definitely won't) fix all the problems it will result in far fewer of them.

Cheers,
Wol

Most likely not at all. There's so much superstition among audiophiles; this used to entertain me, but it got boring after a while.

A low-latency kernel can help, but this is very very unlikely. It will only help if the audio chip's buffer drains empty ("xrun") before the player software can refill it, because the CPU is hogged by other processes. A properly configured real-time kernel will try harder to give the player software a share of the CPU before the buffer drains empty.

An xrun is a very audible thing. If you don't hear it, it doesn't happen, and if it doesn't happen, a real-time kernel has no effect at all. Same goes for any other choice made by this distribution.

Of course, it's a good thing to be "free of unnecessary daemons and services", but that has nothing to do with audio quality.

There are choice which can affect audio quality, for example if the player software (for some reason) decides to resample, or convert to a different sample format. There are ways to avoid it or at least reduce the degradation.

As MPD developer (the player software chosen by Audiophile Linux), I spent a lot of time trying to avoid lossy audio format conversions during playback whenever possible. Even though I'm confident that many such optimizations cannot be possibly distinguished by even the best human ears on earth.

The actual reaper process is very simple: it just calls wait() in a loop. The complicated parts of something like systemd (or even sysvinit) are the parts that set up and run all the services, not the part that reaps processes.

Then almost certainly. There's a "journalistic, artistic, or literary exception" (Article 85) but it seems like that could be a legal nightmare of the "just cheaper to delete your account" kind.

I've got a more tangible harm of not doing that for you: the same people who are unlikely to buy safe food are also unlikely to voluntarily buy health insurance, therefore (when the unsafe food bites them or the unsafe drugs don't cure their disease) they end up as non-paying customers of the hospital's ER, thus forcing increased healthcare costs on the rest of us.

This is not hypothetical. In countries with mandatory insurance, going to a hospital costs an order of magnitude less than in the US.

Not true. *All else being equal*, safe food and medicine are obviously preferable to unsafe food and medicine. However, that condition almost never holds. Safe food and medicine cost more—and given the choice, quite a few people would choose slightly more risky products over safe ones with higher prices. The FDA makes people safer (by some metrics) by forcing them to either pay the higher price or go without, thus trading one highly visible form of harm for another, more subtle kind.

Like most people operating small numbers of machines rather than huge failovered farms, I upgrade at irregular intervals, when a stable kernel with a bugfix seemingly serious enough to make it worth the annoyance-cum-terror of rebooting and flushing all my caches comes along -- though I suspect most people don't routinely read the git log and patch series of everything that hits -stable the way I do. (Rebooting is much less bad for performance than it used to be, thanks to bcache caching all the seeky metadata, but rebooting my core server is *always* terrifying: what if it never comes back up? It always has so far but this is a PC which means it's shit by definition, and I am not confident that all-Intel-mobo-plus-Intel-UEFI-only-one-corp-to-blame means it's reliable before the OS has started, not when I've *seen* the thing lock up once or twice when trying to enumerate its USB ports, exhaust some sort of watchdog timer, and autoreboot again before completing POST. I'm tempted to switch to kexec just to avoid most of that terror, but unfortunately kexec is even *less* routinely tested so the terror quotient would be greater. Yes of course I have backups, and backups of backups, and backups of backups of backups, but terror does not yield to common sense. I keep the ludicrous levels of backups anyway.)

Nearly all of it is useless -- but when something from 1997 turns out to be useful people are amazed that I could dig whatever-it-was up. I have no idea why. Keeping data around and searching it is what computers are *good* at.

I don't know what the dates are for front seatbelts, but obviously they're earlier. But those dates mean that, for almost my entire lifetime, rear seatbelts have been an option on new cars. However, until they became mandatory, many cars didn't have them. I know - in my 1985 car - I had them fitted by the dealer before delivery, so they weren't that common.

Cheers,
Wol

So apparently the users here don't use g+ much. Even I, as a non user, knew it was shutting down since I had an account that I never used, and they emailed this notice out a month or two ago.

Sadly, there is a certain winner take all in these platforms, despite brave efforts to create more free alternatives.

I find the notion that git has to do everything kind of sad, but I guess there will always be people out there who think tacking on more use cases a tool is not designed for is a positive. Those are probably the same people who think using git to download a file is more sensible than using wget or curl...

I don't think that necessarily follows. See for example prctl(PR_SET_CHILD_SUBREAPER) (which lets a process become init-like with respect to its children, without having PID 1).

I do agree that running (for example) systemd with PID != 1 is likely to be a minor headache, but nobody said you have to use systemd (or whatever) as your init system. You could just as easily write a bespoke program that forks off some hard-coded set of children and wait()s for them.

To me, "archive" means stuff I've organised with the deliberate intention of saving - most of what I see is stuff that's forgotten but not gone ...

Cheers,
Wol

Use-case here was to provide a seamlessly takeover from one process to another for critical software upgrade (used for components on mobile core-network).

https://elinux.org/images/f/f3/2017-10-24_ELCE-2017_Bulwa...

Question is, how would you protect the safety application itself (e.g. its memory) from the kernel?

Even if you certify all the relevant kernel parts, how can you insure that the un-certified kernel components will not corrupt the certified ones (ISO-26262 freedom of interference within the kernel image)? This is a monolithic kernel.

Theoretically you can say, we'll certify the absolutely minimum set of defconfig necessary. But then for every feature you'd like to add (TCP/IP, CAN, etc.), you'll have to fully certify it too due to the shared address space.

(There are of course lots of other known challenges, but these two architectural points seem to be the toughest for me to grab my head around...)

P.S. Greenhills Integrity, which is commonly used in the automotive business, etc. solves this problem neatly by having a very tiny nano-kernel, certified at the maximum safety levels. Services on-top (e.g. a file system, a CAN stack, etc.) are still certified, but at less safety levels and so on. That is, freedom of interference has overly clear boundaries...

P.S.S. Of course Greenhills has its own set of problems, including overly ridiculous pricing (tens of thousands of euros for _each_ "extra stack" – anything above minimal IPC and memory management is sold separately – including nowaday basics like file systems, tcp/ip, can, and so on .... not to mention the tight coupling with their proprietary compiler (multi) and IDE, each sold separately too .... all of this is just the basics _before_ even "discussing" the price of a minimal booting BSP and any "customer-specific" request on top ... and they mandate royalties __per each__ HW unit deployed in production. Moreover, and on purpose, no deep knowledge about Integrity exists on the Internet, so you're 100% dependent on Greenhills support for every issue big and small .... This is ok for big fat military and government contractors, but it's no wonder that people in more financially-honest industries want to at least explore other solutions, including linux ....

Unfortunately that kind of software design seems to be becoming a lost art; we can't just go and politely ask all the gtk/qt downstream users to please stop being so lax with the screen updates, so it's a hard problem to fix. For anything on a modern toolkit, all the compositing happens within the application and entire bitmaps are being shoved down the pipe instead. At that point VNC becomes a workaround for the damage (excuse the pun) by delta-encoding those redraws, at the cost of burning even more watts. Maybe all this is why Intel has been adding VP9 encoding to its chips lately…

A lot of other web software also needs to back away from that race to the bottom.

The "Recents" screen shows activities and tasks (which I think correspond to certain Java objects), not apps or processes. When the user closes something from that list, I think it does destroy the activity if it's still alive, per https://developer.android.com/guide/components/activities..., so it's doing more than just hiding it from the list. But it still probably won't terminate the process if that was its last activity - it just increases the likelihood of it being chosen by the Low Memory Killer when someone else wants the memory.

Conversely, an activity can remain in the Recents list after its process has been terminated by the LMK. A new process can be started and told to resume that activity. So there's little correlation between process lifetime and activity visibility.

How do you guarantee that the gateways do not cheat and are not sending data unencrypted? How do you verify this? It's like today's email: how do I know that my mail provider is not broadcasting my poorly written and utterly embarrassing (but really sweet to the addressee) love letters to other mail exchanges as plain text? (An obvious response to an obvious retort: mail encryption is rubbish and my girlfriend refuses to use it.)

BTW, you may be confused that when you "close" an app it is in fact closed. More likely it is just removed from the list of recent apps, unless you're going to the settings > applications > particular app > stop process > yes, I really want to kill it and I know it may break the app. It gets tiresome really quick.

Not exactly sure what you are talking about here, but I would like to point out that in Kubernetes a pod can be made up of any number of containers. When you are doing things like sidecar containers or init containers (as in stuff that runs before the application starts) then you can have containers made by different projects and different people with different assumptions about uids and whatnot.

So certainly you want to be able to audit and interact with things on a per container level. Such interactions should be avoided as much as possible, but occasionally you need to still deal with individual containers. Usually when viewing logs or debugging things.

YES. THIS.

This would make life so much easier.

The GDPR if I have it right concerns the collection and processing of personal data. As such there is no "right to be forgotten", it's more "I don't want to be on your database, take me off" or "the info you have is wrong, fix it". Both are important - why should my details be on your database if I no longer want to "benefit" from it, or even more so if I didn't give you the information (and permission) in the first place! And especially so if said details are wrong!

The "right to be forgotten" is there to prevent old news being dragged back - in Europe we seem to have this quaint notion where convictions can be "spent" and no longer count against someone, and the right to be forgotten - quite deliberately - makes it *difficult* to find such information. But it does not give the subject the right to attempt to delete or alter primary sources. Do *you* think it right that an old man should be punished for the actions of a teenager? I don't think so, and the "right to be forgotten" would agree. And chances are, if the person really hasn't changed, there's a lot more recent stuff around that's easy to find.

Cheers,
Wol

The other issue in the kernel is that after two years the original author isn't around or doesn't want to fix bugs. I seldom bother reporting static analysis issues over two years old. If it's less than two years we are good at addressing those.

People take a lot of pride their work generally.

Also there should be comparison between the kernel communities on all the *nix platforms.

How healthy are those,how do they compare to each other, are developers contributing between linux,bsd and solaris.

Is there rise or decline in one but not the others etc.

I dont think Jon and or other writers here have researched into that, gather the stats and written about it.

1. Migration is currently a matter of using a script or other tool to invite your new account to all the rooms your old account was in, and then (optionally) parting the old account. It's a bit like migrating between IMAP servers, and generally cumbersome and suboptimal. We're trying to replace it by decentralising user IDs, so that user accounts can span multiple servers, at which point we get migration for free. This is https://github.com/matrix-org/matrix-doc/issues/1228.

2. There isn't a global user directory. Directories are instead done per homeserver, and search all users you share with a room with (or are present in public rooms existent on that server). In practice tends to work relatively well, though, as on a busy homeserver, many of the users you want to find will already be hanging out in public rooms (a bit like on IRC).

3. You have to run a TURN server, but we provide easy instructions for how to do so, and most of the docker or ansible setups automate this: https://github.com/matrix-org/synapse/blob/master/docs/tu.... We don't have the same problems that Jami has due to the thinclient nature. Even when we go fully P2P this shouldn't be a problem, given TURN & ICE is pretty straightforward (mainly due to pre-Matrix us being a VoIP stack shop...)

Rooms, on the other hand, are IRC-like in that they aren't associated with any specific server but exist on all servers which have a participant.

2: That's handled by "identity providers" which are sort of outside the core Matrix protocol, and provide a mapping from third-party identifiers (email addresses, phone numbers, personal names, or other identifiers) to matrix user IDs. I don't know what the state of play is for those, really. They exist and have client integration but I think the system is still more of a usability hack than a polished design.

It'd be interesting to include such statistics in coming reports. In the meantime I took the time to get such data for the most active 5.0 developers.

$ git log --shortstat --author=<name> v4.20..v5.0-rc7 | grep 'Fixes:\s\+[0-9a-f]\{6,\}\s\+(".*")' | wc -l

Geert Uytterhoeven 44
Colin Ian King 30
Jens Axboe 18
Christoph Hellwig 16
Gustavo A. R. Silva 15
Ville Syrjälä 15
Linus Walleij 14
Arnaldo Carvalho de Melo 13
Boris Brezillon 10
Masahiro Yamada 10
Yue Haibing 7
Kuninori Morimoto 5
Andy Shevchenko 3
Rob Herring 3
Jakub Kicinski 2
Thierry Reding 2
Michael Straube 1
Maxime Ripard 1
Yangtao Li 1
Paul E. McKenney 0

I wanted to use grep 'Fixes:\s\+[0-9a-f]\{12\}\s\+(".*")' but some people don't use the canonical format. Also, I noticed that some people use this format: Fixes: commit 4d230d1271064. Which may be why this kind of info is not included in the report: it is prone to error. So, due this an other formatting issues, in more than three cases, I had to manually edit the final number.

--Gustavo

Allowing limited flexibility over the current interface doesn't make it non-pejorative. For instance:

1. It has a concept of init meaning it seems to require the PID namespace regardless of the flag.
2. requiring init also requires a container be populated by at least one process. This seems to completely deny the current concept of bind mounting a namespace (i.e. creating an empty container)
3. Nesting doesn't seem to be thought through
4. In kubernetes terms is your container id the container or the pod? The common audit use case seems to imply it should be the pod.
And so on ...

As I said: you can regard the above as bugs or features, but you can't deny it introduces a pejorative view of a kernel container.

The meta point here, I think, is that the notion we've been experimenting long enough to have an idea of what a good container construction consists of is actually wrong and we're still need to experiment further. Which also means we really don't yet want to be pejorative about container constructions at the kernel level because that hobbles the experimentation.

My ISP's gateway, my bank's ISP's gateway, and the six other gateways between my ISP's gateway and my bank's ISP's gateway have no business being able to know my access credentials for my bank's online services.

It's basically down to supply and demand. Why did we have the Renaissance? Because average *median* wealth rose dramatically as a result of the Black Death. That was what brought down the feudal system in a large chunk of Europe. We had the same effect after the First and Second World Wars.

Sadly now we have the opposite effect, where we have too many people chasing too little work, and even while the average *mean* wealth may be rising, the *median* wealth is falling. And politicians love to talk about the mean, while forgetting that in a skewed distribution like incomes, it has very little meaning.

Cheers,
Wol

I'm not a docker apologist but I'd like to point out that docker certainly can take advantage of userns'. At my $day_job I have built a production service that makes use of this. However, userns has a few serious usability draw backs. While it does provide [the rather important] removal of true uid 0 processes from a container, it doesn't provide for unique uid reservations -- meaning it takes careful planning to keep other service role uids from overlapping with the range mapped into a userns. Another issue, specific to how docker uses userns, is that every container has the same system<->container uid mapping, resulting in the possibility for many processes in different containers to all share the real system uid. This isn't a major issue but it certainly feels untidy if the goal is maximum isolation. Finally, the most serious limitation is when trying to bind mount a filesystem into the container for persistence (yes, I'm aware that the "docker way" is use docker volumes but that isn't always convenient and has its own set of limitations) that the userns mapping system<->ns is a 1:1 range and no overlapping is allowed.

Suppose that you want to persist files with a system uid of 5000 and use the same uid inside the container. To do this with a single mapping for the namespace, you'd have to start the mapping at 0 and have a range of at least 5000 uids. That's a no go as then system uid 0 == container uid 0. This means for a lot of scenarios (say, systemd running the container) one mapping is needed for the root uid and one for uid 5000. However, there is now the problem that without caps, uid 0 in the container can't access uid 5000's files unless they are world accessible. It also means that every container run needs to to follow this uid pattern. Want to use a docker image packaged utility (terraform, etc.)? A "wrapper" image needs to be built to change the uids -- exactly the same as it was without userns except now knowledge of the mapping is also required.

I believe what most users actually want is the equivalent of an NFS uid squash between the system and the container userns -- I am aware of an example of this essentially being done using a k8s storage driver. While I am a heavy k8s user, it isn't a realistic to solution to the typical case of wanting to run multiple docker containers in a sequence that interact with the same files, which is why the DinD pattern ends up being employed in k8s pods. Docker storage volumes don't solve this issue either. Solutions other than uid squashing are painful: give up on posix semantics completely and move to object storage, use a utilty with caps to re-chown files, local NFS exports/mounts, and/or FUSE games.

The problem still is that having a container construction imposed from userspace allows for huge flexibility and is incredibly powerful. The down side is that the kernel doesn't know what constitutes a container. The solution we came up with was to have userspace tell the kernel for audit purposes (the audit label) what the container is.

If the kernel is going to impose its view of what a container is, the question becomes which container construction should it be? The obvious answer might be what docker/kubernetes does, but some of those practices (like no user namespace, pod shared ipc and net namespace) are somewhat incompatible with what LXC does and they're definitely wholly incompatible with other less popular container use cases, like the architecture emulation containers I use to maintain cross arch builds of my projects. This is the fundamental problem: imposing a kernel view of container is pejorative and eliminates all other non-conforming uses. The argument is mostly about whether you see this as a bug or a feature.

It wants to be a currency, but the fact that it is deflationary by design seriously hinders its usefulness as a currency by encouraging hoarding. And, in fact, its most significant usage nowadays is indeed a structured form of hoarding: as an investment vehicle. Except it's an exceptionally volatile investment, because its near-uselessness as a currency (the basket of legitimate goods and services you can purchase with it is comparatively limited) means that there's little of economic substance backing it up--so its ability to be traded for real currency is essentially arbitrary, subject to literal mood swings and propped up only by delusion rooted in economic illiteracy.

Bitcoin's greatest value, I think, is its ability to serve as a case study in why being brilliant in one area doesn't get you very far: everything you do has to interact with the wider social environment. Those humanities and social science general-education requirements were actually pretty damn important.

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

I wonder if any LWN readers work for Apple and could escalate this issue.

I really don't think that pointing the finger at who produced a bug is ever helpful (except to quietly let them know so they might learn from the experience). All the bugs belong to all of us.

Conversely, highlighting people who fixed lots of bugs would do no harm and could be beneficial. Even better is highlighting people who fixed a bug and made it clear when the bug was introduced so that an informed backport to -stable is easier. This is a valuable contribution worth celebrating.

> 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
Brazil was at GMT-2 also during part of the 5.0 development cycle.

Now binned because it broke, but I had a Logik / JVC TV that used to crash when you tried to record to USB. It did it somewhat at random but that's obviously very annoying.

My car stereo now seems to spend an inordinate amount of time "scanning USB" which impacts quite seriously on its usability - I think that's a bug ...

And trying to get this sort of stuff fixed is a nightmare, as it's almost impossible to contact the manufacturer, and the retailer's attitude is "well almost everything works". The fact that the bit that doesn't is very important to you, isn't important to them.

Cheers,
Wol

The idea that mere linking make the source code a derivative work is akin to saying that any research paper is a derivative work of every piece of source material listed in its bibliography.

A *binary* distribution is a different matter, since it actually incorporates elements from all the different sources which are linked together. That wouldn't include any shared libraries, but it might include code in header files (e.g. macros or inline functions).

Probably by not lending physical gold, just giving out a transferable piece of paper saying "I promise to pay you 100 gold if you ask me to" while not having enough gold to cover all the notes they give out, and without those notes becoming ubiquitous enough or official enough to be counted as currency by any reasonable definition of "currency".

That depends on trusting the institutions giving out those notes that even though they don't have enough gold for everyone, they've been careful enough to be pretty certain that not everyone is going to ask for their gold at once. Experience shows that that generally works pretty well, but Bruce notes that Bitcoin was explicitly designed to avoid relying on trust in institutions. (And it doesn't even succeed at that, given how many people still trust their cryptocurrency to exchanges that invariably get hacked due to incompetence or simply steal their users' money.)