Recently posted comments

CTF is lightweight enough (cf DWARF) that GCC and clang could emit CTF data by default without too much hemming and hawing; we could rely on its presence and enjoy a world where we could not only statically analyze compiled objects, but also generate FFI accessors dynamically at runtime with strong type safety.

So, they have no control over what goes there, except they control the modules that go there, which means they do control what goes there.

"In a system whose functionality requires multiple *independent* parties to work together."

Except one party forces the others to build their kernels in a certain way through some contract, so they aren't independent.

What is going on with these unexplained contradictions?

First, I wanted to write a flame about the disregard of the difficulties of disabled persons to create a "website [that] is not really optimized for modern browsers or responsive design" [Zenith, start of this thread]. Having disabled firiends, this really irked me.

On 2nd thought, I realized that being able to read a Web site on small-form systems is a kind of accessibility in our world of today -- where many people don't have desktop systems any more, especially in 3rd world countries where people only have smartphones and have no chance at all to use a "real" computer.

So I realized it's really the question who you target with your Web site: as many people as possible (then RWD is a must), or a smaller group (IOW, a minority) where data is much more important than representation.

That question is not easy to answer and depends very much on the situation of the project and the person who's creating the Web site.

Of course, in the best of all worlds, we would have the means for disabled persons to easily create Web sites with a RWD. But -- as an example, go to https://getbootstrap.com/ and try to gather an idea how to create a site design *without being able to see* the information there. IMHO, that's near to impossible. The result of that non-availability are Web sites like ADRIANE that feature data above ease of accessibility for the masses.

I don't think I've ever heard the unqualified term "accessibility" used to refer to "it works well on small touchscreens".

At this point, I question the relevance of any numbers you get comparing these a.out binaries to modern systems. You're comparing a program compiled for the original Pentium with GCC 2.7 (at the latest) and libc4 to a different program natively running on a recent version of AMD64 using modern versions of GCC and GNU libc. Where the faults lay for speedups and slowdowns is going to be very hard to tell. In any case, for the near future, you can run a Linux 5.0 kernel in an virtual machine if you want to compare things.

I'm not Linus, but I'm certainly more worried about some of the lost filesystem support making file recovery quite complex than I am about forcing a.out binaries to be run via qemu or a userspace loader, if anyone cares to write one. Supporting ancient binaries is much better and easier handled by emulators than trying to maintain a 25-year old environment mixed in with a modern one.

Ideally I'd like the application to degrade in a localized and controlled way. For example, if the battery applet on my panel, which calculates the % of charge dividing the current charge by the max capacity, faces a divide-by-zero for whatever reason (say, a hardware failure of the battery control), it could simply show 0% or 100% or even a meaningless value, and yet this would be ways better than killing the whole panel[1].

So yes, sometimes wombling on doing stupider and stupider things is the desirable approach.

[1] In fact, this is not a made-up example but a real case with LXDE panel.

For you, "accessibility" is the ability to read the Web site on a mobile device.
For Adriane, "accessibility" is the ability to read the Web site as a blind person.

I.e., you care primarily for smartphone users, she cares primarily for blind persons.

It is an interesting question which interpretation is more important. While your concern affects more users over all, but they are users who have means to get the information; her concern is about a minority that is much more severly encumbered than your target audience. So, is an inconvenience for a large audience important enough to promote it against the convenience of a disabled minority? Reader's choice.

Trolls are not welcome here around.

Intel developed an ARM-to-x86 binary translator (Houdini) for their Android BSP, for compatibility with popular apps that contain ARM-only native code; I suspect that's why it worked. I doubt anyone has done it the other way round, because there are approximately zero Android apps with Intel-only native code.

There have been tunnel solutions ever since IPv6 started. 6to4, Teredo, 6rd. And NAT64, 646XLAT, etc.

There's just not much advantage to it unless it's used natively and that's the hold-up.

Really, there's a ton of slow and stupid solutions if all we wanted were more IP addresses. My favorite proposal I heard someone make was automatic IPSEC tunnels and new DNS records to get the second layer of IP once you had a tunnel up. Because that way you got the encryption *and* the tunnel.

So you'll inevitably also be able to roll your own, and $BIGCORP would necessarily have to sell a service (not a product).

With regards to the on-ramp, it's very project dependent, I guess. And FLOSS always starts with "scratching an itch". So market research is irrelevant. And time usually tells whether the itch has wider appeal or not.

Finally, factionalisation is simply the same as "standing on the shoulders of giants".

No project does everything from scratch. Almost all software projects require intensive work up front, with the intensity and frequency going down quite rapidly after a certain level of function is reached.

Funding therefore may not be able to follow that pattern anyway. Who will fund $MYFANTASTICNEWVIDEOEDITOR before it exists?
I will have to show a functional *and reasonably superior* Video Editor _before_ I can expect any funding at all. We're back to scratching itches!

Bottom line: sustainability is certainly achievable (as others have pointed out). We wouldn't be here if not.

http://share.find.coop/doc/tutorial_git.html#tutorial_git...

To do new things you need to slice up the new problem space in layers, to keep the complexity per layer to a manageable amount. But, managing layers is itself a complexity source.

So, the cost of doing new things, is to simplify the existing layer pile, to free up the complexity budget required to handle the new layers. And simplifying mostly means giving up on some layer combinations that seemed to have potential in the past but proved not worth the layering cost.

You see this a lot in human languages. All human languages are different. Pretty much any human language will be simpler and more regular than others in one aspect. But this simplification usually freed up a complexity budget, that humans used to make the language less simple than others on some other aspect.

Rather I meant it as an observation about how developers never can expose any api, whether intentional or unintentional, to users without exposing their product to either ossification or disapointment when the api is modified.

Personally, I don't see that this is a good addition to the language. It won't get a lot of use. If the operator "+" is used, I bet that more examples will be accidents rather than intentional.

Dictionaries are functions, in the mathematical sense. If they were relations, then + would make more sense.

But honestly, if Mozilla engineers make a change and claim it's because it makes things measurably faster, why wouldn't you give them the benefit of the doubt? Or at least go look in the relevant Bugzilla bugs to see what they say they did and measured, before casting doubt on it?

I probably should have noted at the start of my talk that I was somewhat assuming folks hearing it knew the basics of how fiscal sponsorship is generally set up in the FOSS world right now. Different organizations have different structures that's orthogonal to the (c)(6) vs. (c)(3) issue (which I covered). For example, Apache Software Foundation is also a (c)(3), but they do *not* accept earmarked donations for specific Apache projects. Conservancy, SPI, GNOME Foundation *do* accept earmarked donations.

So, in the latter case, you can donate specifically to the project rather than generally to the organization. In fact, in my slides during the talk, the numbers I showed for phpMyAdmin were *specific* to phpMyAdmin (donations that Conservancy received specifically earmarked for phpMyAdmin).

arm64 allyesconfig needs this series: https://lore.kernel.org/lkml/20190318025411.98014-1-trong...

asm goto is still a WIP in clang so a set of reverts is needed for x86 (otherwise, defconfig and allyesconfig build without any issues).

https://travis-ci.com/ClangBuiltLinux/continuous-integration

It's certainly true that the data could be read via some shared firefox mechanism from a config cacher or whatever to the renderer process, skipping the need to have a specialized datastore, but maybe this was easier to do?

https://github.com/ClangBuiltLinux/linux/issues

I spend my F/OSS time immersed in printing-related stuff. It's an utterly necessary requirement for most desktop users, but it's rarely given any attention unless it doesn't work. It's also something that the general public won't fund, because they already paid the printer manufacturer; why should they be expected to pay more to use it?

In this space, any distinction between "big business" and "general public" is artificial; _everyone_ benefits from printing that JustWorks(tm) while exposing the full capabilities of the printers. However, _someone_ has to do that work, and if not for "business" users, a lot less would get done, to everyone's detriment.

Duff's device a hard-error? Heresy!

Besides, projects that are useful for end-users instead of companies is exactly what Bradley was talking about: "As a community, we need to consider ways to prioritize the needs of the general public, not necessarily the needs of big business, he said. ".

And that's what I'm doing.

But on an individual level, donations need to hit a non-trivial threshold (on a recurring basis) before they will allow someone to quit $dayjob in favor of F/OSS. One has to keep a roof over one's head and food on one's plate, after all.

All that said, thanks for all your work in this area from a happy supporter of LWN, SFC, and Mozilla. ;-)

Ada has had integer overflow checking since forever (as you would expect).

> Even on our worst-case-scenario stress test — AWSY which loads 100 pages in 30 tabs, repeated 3 times — we only saw a 6% increase in memory usage when turning on 8 content processes when compared to when we started the project.

Sorry to correct you, but I think you mean "It is correct that 'The Therac-25 killed three people' ".

And this is the point - when people start using broad terms like "intent" and "correct" without ensuring that all corespondents are using them in the same sense, you can hardly expect a useful conversation to result.

(wouldn't it be great if people would think about what they write, instead of just writing about what they think).

*quietly sobs into a pint*

I keep the settings for some of my extensions under version control, and I really enjoyed being able to create a symlink from the firefox profile directory to my repo.

Yes it is.
Your statement "I have this code snippet: a = b + c" is self-evidently correct.

Most versions of Linux can't run ix86 binaries; only those compiled for ix86 or AMD64 can. Had Intel had their way, we'd be running Itanium without direct support for ix86 binaries. Perhaps in five or ten years, we'll be running ARM64 without direct support for ix86 or AMD64 binaries.

We can better study something in its home environment, not by running it on a modern system where various things might not work (audio, modern resolutions, USB).

Out of the box, Retropie supports the ZX-Spectrum, the TI-99, the MSX, the Atari ST, the Coco, the Colecovision, the Amstrad CPC, Amiga, SAM Coupé, the Macintosh, MS-DOS and the Commodore 64, along with dozens of other, usually more gaming focused, systems. It seems unlikely emulating x86, one of the most common computer hardware platforms of all time, will be a big problem for the foreseeable future.

You're demanding that Linux accept your solution for your obscure problem; there's not that many people who ran Linux before 1996, and many of those have given up all their old binaries from the time. If you were volunteering as a maintainer, you'd have more say in if this feature stays; if you were looking for solutions to a problem, people will be more willing to help. But to demand that a feature that doesn't fully work (i.e. core dumps were broken) be the only possible solution to your problem isn't helpful.

So we had to split up our activities into a non-profit that receives donations and doesn't have to pay VAT over expenses made outside the Netherlands in the Netherlands. (Basically, where Dmitry lives, there's no VAT on coding, and where Ramon lives there's no VAT on producing art.)

The commercial activity -- a little bit of sales of training materials, income from Steam and the Windows Store and the occasional project we do together with Intel, is handled through my company. When work is done on those projects, my company is billed, otherwise the Krita Foundation.

We're still running on a shoestring budget, of course, but that's fine. We probably could do more with donations, given that we have about 2000 euros a month in donation at 2,000,000 downloads a year. Our yearly fundraiser provides the other half of the donation income.

I've been managing to pay a full-time developer for Krita since 2013, on donations, myself since 2016 (more or less, I got through my savings during some dark periods), another person since 2017, and this month a fourth person has started. I've also funded the initial development of training materials. Nobody is earning Silicon Valley money, but on the other, we're having lots of fun.

The Blender Foundation is doing extremely well with their new development fund system, something I'm very eager to copy as well.

Even Inkscape, which long held out against funding development, seems to be considering starting to fund some development because they're recognizing that there are just things that are too hard to develop in one's spare time -- like we did when we hired Lukas Tvrdy in 2009 (https://dot.kde.org/2009/12/02/krita-team-seeking-sponsor...)

The GNOME Foundation is sponsoring development of GTK. There are quite a few other examples, each with their own particular quirks, of course.

And, yes, there are still plenty of free software organizations that aren't trying to fund development, but only collect funds for things like sprints and hardware -- which I do feel is indeed a bit of a pity.

Unfortunately, C made that useless and so it fell by the wayside.

Interesting to read that increasing the number of threads reduced crash rates :) .

I mean, I really don't know, but I expect most of their income hasn't been via SuSE Linux Enterprise for some time, because it isn't a growing market. The datacenter was pretty saturated with Linux a decade ago.

I do think that in around 10 years, datacenter spending will have rebounded a bit, but I expect its management will look more like the cloud than its current reality.