Recently posted comments

I don't see anything wrong with this. Of all the changes from the linked article, this is the least controversial. This has no runtime/compile overhead or any form of weird semantics. It doesn't obfuscate the code base. This change has zero negative impact. If anything, I'd ask for using the related gcc attribute instead of a comment.

Besides, this has been standardized in C++17. The only reason it's not in C is that the C committee is run by a bunch of stick-in-the-muds.

A cavalier attitude of ignoring the simplest safety features has led the industry down the never-ending rabbit hole of security bugs.

In theory, we're past the point were "Charge and beat 'em!" was an acceptable discussion tactic.

Switching the topic of a discussion away from something technical and towards posting speculative, public insults about people who happen to disagree with some opinion is not a strong point in favour of this opinion. Rather the opposite.

It's not about fixing the people - they've already been fixed. When observing people carrying out a task, if they keep doing the same thing wrong, ask yourself why.

It's a pretty safe bet they're doing EXACTLY what they've been trained to do. It's just that the task they're doing is unusual, and their training is making them do the wrong thing.

Case in point - who was the idiot that decided that in Windows "tab" should step between fields, and "return" should send the completed form back to the program. It took a MAHOUSIVE training effort to fix that programming blunder, and people STILL get it wrong on a regular basis.

If people can't do it right, IT'S BECAUSE THEY'VE BEEN TRAINED TO DO IT WRONG, and you've got to *find* that training and fix it - which may not be possible.

(Another case in point - these latest 737 MAX crashes - the plane avionics have changed, and it seems pilots haven't been told that 20 or 30 years of training will make them instinctively do the wrong thing in a crisis ... - TRUE STORY!)

Cheers,
Wol

>>> { 'apple': 5, 'pear': 7 } + { 'strawberry': 2, 'pear': 10 }
{ 'apple': 5, 'pear': 17, 'strawberry': 2 }
>>> { 'x': 'abc', 'z': { 'a': 13 } } + { 'x': 'def', 'y': 'ijk', 'z': { 'a': 9, 'b': 10 } }
{ 'x': 'abcdef', 'y': 'ijk', 'z': { 'a': 22, 'b': 10 } }

This would make it similar to the Semigroup operator (<>) in Haskell.

If that guarantee is broken you can of course demand your money back - you see where I'm going with this?

git push
fatal error: no such file: path/to/some/lfs/file/on/another/branch

Note that this particular error is now better worded in that it mentions the object id that it is missing instead.

There's been other problems like this; Fortran require you to declare variables, so when programmers misspelled variable names, the compiler wouldn't warn the programmer. So those still using Fortran have the option of using "IMPLICIT NONE", not too dissimilar to C programmers having an option to have the compiler complain when they don't use a break or a note comment.

But if there is support, I'd argue strongly against using + and - operators. This is far more likely to lead to accidents than using |. This latter operator is far less frequently used, and seeing it always alerts one to the fact that something out of the ordinary is going on. Also one can visualize a set as a dict where all values are the same and irrelevant, such as True. In fact back before we had sets, that's what we used to do. So extending the set | operator to apply similarly to dicts makes reasonable sense.

Subtraction I like even less. Non-commutativity I can live with, but subtraction completely ignores the values in the dict being "Subtracted". A much better idea would be a dict.subtract( other) method.

Current situation is further complicated by very low barriers to entry.

https://osmocom.org/projects/quectel-modems/wiki
https://osmocom.org/news/63
http://git.gnumonks.org/laforge-slides/plain/2016/cellula...
https://media.ccc.de/v/33c3-8151-dissecting_modern_3g_4g_...

You do lose the ability to roll back using BTRFS snapshots and automatic upgrades though. Also some minor stuff (like nice rainbow LEDs) is not supported by the stock kernel.

Personally I'd support people being free to chop off their own body parts if they insist on using unsafe equipment or unsafe programming languages, except that some of the costs inevitably fall on the community at large. For amputations, it's health care costs. For software, it's a combination of things: a software ecosystem polluted with vulnerable software, and a network ecosystem polluted with compromised devices.

The gas story is a good one.

I'd sort of guess that, if you've got an "or"-like thing, even if it doesn't short-circuit (i.e., evaluates all of its arguments), it'll pick between distinguishable values with the same truth value as if it were short-circuiting.

Dangerous statement :-) What about i?

Cheers,
Wol

In reality people make mistakes. A lot of time.

A good example here is surgery. A surgeon is a highly trained professional, you need almost a decade of intense training for it. In short, a surgeon is the first candidate for somebody who shouldn't make stupid mistakes.

Yet surgeons forgetting instruments inside patients was a common occurrence before a simple check was added - nurses count surgical instruments before and after the surgery.

Aviation? The same issue. Solved by checklists that HAVE to be followed.

Just out of curiosity: Have you ever seen a bread slicing machine? Chances are that someone who doesn't get "using that" right every time will end up cutting off a part of his or her fingers. That's a seriously bloody and quite painful experience. Yet, people without a degree in anything are expected to be able to do that.

NB: This is still completely besides the point I was trying to make, it just illustrates that "misues of household devices is harmless !!! but misuse of switch Catastrophical !!1" is an nonsensical assertion despite misuse happend to be harmless for an example I used because it served as illustration for something completely different.

Random story I feel like telling here: A couple of years ago, I read about a guy who was resolved to commit suicide and thus, turned the gas on in his kitchen. After waiting for terminal results for a while, he suddenly changed his mind, turned the gas off again and opened the kitchen window. To celebrate his decision to face this life somewhat more, he then lighted a cigarette. The roof of the house was blown of but he survived with serious burns and was later sentenced for arson.

/* fallthru */

to express that they were actually planning to use a certain language feature in a machine-readable way is seriously old. The effect of this is that features someone considers particularly disagreeable become somewhat more complicated to use and that the code becomes cluttered (to a degree) with completely useless comments. Presence or absence of such comments doesn't indicate anything about correctness or incorrectness of the code.

1. Single pipe is traditionally commutative (bitwise OR, set union, etc.). It has been used non-commutatively (shell pipelines), but that usage is so far afield that it provides no intuition here.
2. Double pipe (or the "or" keyword) traditionally short-circuits to the left. I've never seen it short-circuit to the right.
3. Plus is sometimes commutative, but its noncommutative uses traditionally preserve the order of items (concatenation) rather than allowing one item to "override" another. So the closest analogue here would be c = ChainMap(a, b) (so that you have c.maps == [a, b]) as Hettinger suggests... but that actually gives precedence to the left! ChainMap.new_child() does give precedence to the "right" in a sense, but it's type-asymmetric (self is a ChainMap, the argument usually isn't), and probably should not be an operator at all.

I don't expect people to put the right key in the right lock first try every single time, just like I don't expect C developers to always remember to put "break" after switch cases. But because the consequences of the former are "it didn't work, try again" (i.e. negligible), it *is* reasonable to expect unskilled people to successfully enter their flat. The goal of the changes reported here, which you apparently oppose, is to change the consequences of omitting a "break" to something similar (whereas currently the consequences can be much more severe and fall on other parties).

> %hash2 = (%hash1, %hash2); # %hash2 values will take priority

There are other ways to handle it if you need to watch memory usage in pathological cases, but sometimes simple things should be simple.

Lots of tooling existed before but being part of the compiler makes them more readily available and even better if it is the default.

That I happened to use an example to illustrate something specific (complicatedness of a procedure) doesn't mean any side properties of said example are relevant to the discussion because they exist (or are believed to exist).

Absent the kind of work described here that you are objecting to, omitting a "break" is not immediately detected and can have lasting consequences up to and including users you don't even know having their systems compromised by hostile forces.

It would be a better analogy if every time you touched a lock with the wrong key you got an electric shock. It would be interesting to see how long you tolerated that situation because "human beings without any qualifications should be able to do this".

All the empirical evidence including plenty of research and billions of dollars spent on fixing bugs in such code clearly indicates otherwise.

> And adding /** I really disagree **/ comments to source code doesn't improve that (the code).

That's not really what is happening here though. The specific comment here is being parsed by the compiler and therefore really is part of the code.

The C switch statements has certain properties. One could argue whether all of these properties are really desirable, but that's not going to change it. And adding /** I really disagree **/ comments to source code doesn't improve that (the code).

I have to open three different locks with three different keys when trying to get into my flat. Two of them even look identical and can only be distinguished by knowing their relative positions on the keyring. This is vastly more complicated than remembering that a break needs to be added to the end of 'a switch case 'if execution of code in the corresponding block is supposed to be terminated. Yet, human beings without any higher qualifications are expected to be able to do the former while it is claimed that "nobody" can do the latter. Strange, isn't it?

Whenever people have to make a decision, they'll sometimes get this decision wrong. But they will usually get it right most of the time, as evidenced by the miniscule number of missing breaks (compared to the size of the codebase) found during the course of this (a Linux source I happen to have lying around here contains 45,021 switch statements. 20 missing breaks in n * 45,021 cases, n > 2, is decidedly miniscule).

Definitely!

In fact, Ruby provides a way to do it *without monkey-patching* called Refinements:
https://ruby-doc.org/core-2.5.3/doc/syntax/refinements_rd...

So if you wanted to extend the Ruby Hash class (equivalent to Python Dict) in this way with method #+ and #+=, you could create the following refinement module:

module HashWithPlus
refine Hash do
alias_method :+, :merge
alias_method :"+=", :merge!
end
end

Then, in any lexical scope you can say:

using HashWithPlus

{ "a" => 1 } + { "b" => 2}
=> {"a"=>1, "b"=>2}

With no monkey-patching! The refined Hash will only be visible in scopes that explicitly use the refinement.

(just sharing for those interested)

A driver capable of managing more than one device would obviously need one cache per currently managed device. Do you think somebody wouldn't immediately recognize this if such a driver was under discussion?

What about "fixing" people writing code in C (the language is not that complicated, mind you) instead of inventing one bazillion
/*** OMFG !! Not like Pascal !!! ***/ pseudosyntactic tags?

"-Werror=implicit-fallthrough" would be more effective, but you'd have to get all the way to zero warnings first.

> supports the “BDFL” FOSS governance model, which has already been widely discredited

u wot mate?

It would be nice if Linux had the PROC_REAP_KILL stuff. I think one could improve the FreeBSD interface a tad bit when incorporating it, but the concept looks sound.

systemd ofcourse has one supervisor per context (system or user), but this will be especially useful for supervisors that have one monitor per service (s6, runit style), and that these can be nested supervisors (so an option to not cross subreaper boundaries where each supervisor is a subreaper, or a way to kill inherited children only, and a way to kill direct children only, and OR the flags to do both). You could get creative, but if done right, this could solve a lot of woes with process management.

"This new LF system is probably just right for FOSS projects that (a) prefer to use single-point-of-failure, proprietary software rather than FOSS for their infrastructure, (b) do not want to operate in a way that is dedicated to the public good, and (c) have very minimal fiscal sponsorship needs, such as occasional reimbursements of project expenses."

Just another LF attempt to look like a part of our community and failing?

The page cache would need to be separate for each *device*, not each driver. A device snooping on itself may be harmless, but the same is not necessarily true for snooping on other devices managed by the same driver. Besides the fact that one driver might manage multiple brands and models of devices, some more trustworthy than others, one can also envision e.g. a system with two identical NICs surreptitiously snooping on each other and transmitting internal network data over the external network.

"i3 is a tiling window manager designed for X11, inspired by wmii, and written in C."

Regarding Sway, from their website:

"Sway is a tiling Wayland compositor and a drop-in replacement for the i3 window manager for X11. It works with your existing i3 configuration and supports most of i3's features, plus a few extras.".

Some of the previous (lead) developers bought that code close to the hardware has to be C. That code is terrible and impossible to unit test. We recently had to spend a lot of hours patching for a simple memory leak, which simply wouldn't have happened with modern C++ code style (smart pointers).

The Java code is a lot better than the C, but there are way too many treads.

I agree with one huge problem in C++, though: It doesn't scale to large project, since each project around choose their own subset of the language and conventions. When you try merge the projects in one binary it falls apart. Java is much better in that sense.

Yes. I thought I already wrote this ("this should really be all kinds of devices"): If this issue is supposed to be mitigated by the IOMMU, any driver which supports DMA would need to use its own DMA buffer backing pages cache. There's no need for individual buffers to span a complete page (or some number of complete pages) provided management information used by a driver isn't kept in the unused parts of some page a part of which is currently used as DMA buffer, at least not in a way where corruption could go unnoticed. Malicious device snooping on itself sounds pretty harmless to me ;-).

Assuming that fixing this is considered desirable (the underlying issue has existed forever --- there's no reason why hardware designed by an unknown entity ought to be trustworthy, especially not if this 'hardware' is in itself complicated enough to contain a general purpose CPU running some decidedly non-trivial software), this cries out for some sort of infrastructure support for DMA buffer allocation drivers could easily make use of.

NB: I understand the benefits of the existing approach. But that's still just life-patching of a more fundamentally deficient (in this respect) memory management model.

Assuming that memory protection/ accesss control with page granularity is available, DMA buffers used by untrusted devices (and this should really be all kinds of devices) must not share memory pages with code whose information said untrusted devices are not supposed to access if the access control is supposed to be used effectively. This means *if* such a facility is to be used in a sensible way, DMA buffer allocation must be per-device and separate from all other allocations, including other DMA buffer allocation.

There are obviously tradeoffs here as most real-world devices won't be untrusted but singling out a certain kind of devices and adding an additional DMA buffer allocation system working on top of the existing DMA buffer allocation systems is a technically seriously unpleasant workaround for a highly unlikely fringe case.

Which is probably what you were getting at.

Continuing to support the a.out format has risks. The initial proposal to remove the a.out coredump support was due to bugs being found in it. Given the amount of testing the a.out code receives as a whole, I have little doubt that a determined attacker could find a security hole to exploit in it.

Since you appear to be a programmer yourself, how would you like to take up Alan Cox's suggestion of writing an a.out loader entirely in userspace?

Specifically, the configuration file (mainly bindings, workspace settings, etc.). I assume there are new variables in sway for the bits that Wayland expects compositors to provide over X's requests of window managers.

https://lore.kernel.org/lkml/20190312060005.12189-1-baolu...

This has now been made explicit: https://lists.debian.org/debian-vote/2019/03/msg00014.html

Woof !

For people who are as confused as I was, there is also a lesser known "i3" which is a form of window manger. I presume sway is compatible with the i3 window manager (in addition to Intel i3).

Linux has a general purpose kernel memory allocator. This is a power-of-2-freelist allocator sitting atop the page allocator (more precisely it's implemented as set of object caches for objects whose sizes are powers-of-two). As detailed in the paper, the e1000 driver allocates skbs via kmalloc. This means its network buffers will usually occupy some part of a page. An access control mechanism with page granularity thus cannot prevent malicious devices from accessing the remaining part of the page. As that's just one of the pages currently allocated to one of the kmalloc caches, any other part of the kernel which uses kmalloc could end up using this "remaining part of the page".

The gist of this is that a (page-based) IOMMU can only prevent malicious devices from accessing data they're aren't supposed to access if the devices drivers used for such devices do their own memory management based getting complete pages from the page allocator.

It's a much *larger* ad-hoc informally specified bug-ridden slow implementation of half of Common Lisp. :) C++11, in particular, adds lambdas to the language, for extra bonus lispiness. :)

(I was actually about ready to give up on C++ until C++11, which returned to the list of languages I don't mind *too* terribly.)

There are no "data structures" in C standards, there's just a convention for representing strings.