EmanueleAina

The flip side is that women that behave as you depicted often get labelled with unfunny names, while it does not happen when said behaviour comes from a man. :/

I guess not everybody perceived the tone in the same way. It seemed much more neutral to me.

Not sure about that, see my reply to your original message.

As for "you fundamentally can't make code released under Apache more restrictive down the road", isn't that exactly what LibreOffice (LGPLv3) people do when they import patches from Apache OpenOffice (ALv2)?

> AGPL3 maximizes options down the road. You can start AGPL3 and loosen it up over time.

I'm not sure you can easily do that, unless all the contributors assign their copyright to you. You can trivially tighten the license (eg. by adding GPLv3-released code in a LGPL or even Apache codebase) but to loosen it you need approval from all the copyright holders (which is doable, but also a huge pain).

For sure the storage format should not hinder you from using grep if you want. Even with systemd you can pipe journalctl's output and use the same old regexes as its default behaviour is to be a glorified `cat` (but being able to use the --since and --until flags instead of matching date ranges by regexes makes it much better than `cat` for me).

There's a good chance that you'd be reading EBCDIC logs. :)

40 years from now, you will probably be able to invoke journalctl on the system and parse the dumped output as plain text. Or call gunzip on the compressed logs, $DEITY knows if we will be still using gzip by then. And if the system does not boot, you won't be able to connect the peripherals anywhere else... :)

Sure, on a site that uses ElasticSearch for its logs I would have no idea where to look at. I'd be more at ease with SQL, but first you need to locate the DB, figure out the schema, get the SQL dialect right.

That said, I'd be far more at ease writing a SQL query to extract analytics from logs than cooking up some regexes and doing complex stuff with awk.

And I find the --since/--until parameters to journalctl far easier than matching dates by regex. Or even the --boot parameter to restrict logs to a specific boot, which with would be probably doable with awk but definitely not as trivial.

I think that binary logs give you some compelling features, without taking away any: you can always just dump the logs on stdout and use grep as much as you want. :)

> a binary file, that you did not know how to decode

I guess nobody ever advocated putting stuff in a binary file with an undefined format. Databases, syslog-ng, elasticsearch and the systemd journal all have a defined format with plenty of tools to access the data in a more structured way (eg. treating dates as dates and matching on ranges).

I agree the issue at hand is not just binary vs. plain text, it's more "how much you want to structure your data".

The classic syslog format is very loosely defined, with every application defining its own dialect, each with its own way to separate fields and handle escaping. To fix that you could store the log data as JSON as many online services are doing. But once you have JSON, grep is no longer enough to properly handle the data even if it's still plain text. Now that you have both a quite verbose format on disk and the need for custom tools, why not store the log as binary encoded JSON (eg. something like JSONB in PostgreSQL)? Or make it even more efficient with an format optimized for the specific usage? Add some indexes and you get more or less what databases, ElasticSearch and the journal do.

Also keep in mind that most of the logs right now gets rotated and compressed with gzip, I'd doubt that the above binary formats are less resilient to errors than a gzip stream.

> The fact that your DNS data is enumerable is an important change, for example.

Indeed, but afaik there are methods to mitigate it (NSEC3) and more refined ones in development (NSEC4, NSEC5).

Yes, they are moving out of the server those pieces that benefits the most from being client side (scrolling, cursor, selection) but the document rendering/editing is still done by a LibreOfficeKit process on the server.

Reimplementing the whole LibreOffice in JS/CSS/HTML is totally another beast (see https://news.ycombinator.com/item?id=9263233 about WebODF).

I beg to differ: hacking stuff is the real essence of the hacker subculture. Being rude is completely orthogonal to hacking.

Tbh I think in the Linus case the one using a less-than-welcoming tone wasn't Sievers. :)

Of course they have a strong vision, and popping up proposing something that has already been discussed to death and rejected won't be the most pleasing experience ever (it happens all the time here, I don't even want to imagine how tiresome it should feel for them).

Yes, it will be officially supported as systemd is simply a default, not a requirement, as defined by previous CTTE deliberations and as implemented even before them by the Debian systemd team, which has gone to great extents to make sure you can happily switch back and forth with almost no issues.

Lennart has produced some "friction" in the past but now that he's been for such a long time on the other side, getting blamed and accused of every silly thing in the world I hope it has changed his ways a bit.

Truth to be told, the systemd community has been reported as one of the most welcoming and productive environment in the FLOSS ecosystem.

I haven't seen any sign of systemd going in that direction, though.

But `netstat` was already broken for xinetd-started services. I get that it probably didn't affect you, but it means that `netstat` already had its shortcomings.

Now that socket-activated services may see more widespread usage, hopefully someone interested will add to `netstat` the ability to tell who is listening on the socket and not only who opened it (all the data is available in /proc, which netstat is using already).

And in the meantime there's always `systemctl list-sockets`.

> So systemd is doing a reverse proxy for Apache in that configuration?

Nope, systemd only opens the socket and passes the fd to Apache.

> Or is it launching Apache on demand like some sort of advanced inetd?

Yes. Since it's already init's job to start services, it does not make any sense to have a different system to start socket-activated services.

At least OpenBSD had a GSoC to investigate a logind replacement: http://www.openbsdfoundation.org/gsoc2014.html#systemd

> Which won't allow you to install certain core pieces of Debian software which have decided to rely on systemd.

Debian is committed to support sysvinit for the next release at least. I really doubt anyone in Debian will add dependencies on systemd "just because": if they do so they may have compelling reasons (eg. ConsoleKit is unmaintained and broken) and the correct reaction would be to fix the issue (eg. like the ConsoleKit2 people are trying to do) rather than forking Debian just to ignore the issue.

Not that forking Debian is bad and people should not do it for whatever irrational reason if they want: it's just that in this case there's no rational reason the same task couldn't have been carried over in Debian itself other than the fact that in your own fork you may accept lower quality contributions more easily.

You can also encrypt N files yielding M > N blocks, to avoid much of the issues you described while still avoiding the one-large-blob concern.

Qalculate has both a GUI and a command-line `qalc` util that does what `calc` seems to do and much more:

http://qalculate.sourceforge.net/

That may be the case now that FLOSS is worldwide renowed and people are starting to realize that private forks are costly, but it wasn't always so.

The GPL was instrumental in forcing people to behave when nobody knew what to do, and it has been so successful that now people expect the behaviour enforced by it even when using more permissive licenses.

That's the intention, but more work is needed.

Aaaand GPG signature added!

He probably didn't care because it's not much more than partitioning, running debootstrap, installing the few extra packages and copying config.txt and cmdline.txt. :)

That said a gpg signature could be a good thing to add.

Indeed, that was the point of using bmaptool: the actual used space is about 1/10th of the whole image, weighting around 400MB, and with bmaptool you can avoid writing a lot of zeroes to the SD card.

The data is more or less split like that:

224M usr 90M lib 67M var 11M boot 5,8M bin 3,3M sbin 2,9M etc

Of course with some customizations one can do a lot better, but this is just a straight Debian installation with documentation, locales, translations, manpages, etc.

Yep, but the point is about running real Debian, not any Debian-derived distributions like Raspbian that have been rebuilt for ARMv6.

With the old Pi it was not possible because the CPU only supported the ARMv6 instruction set, while mainstream distributions (Debian, Ubuntu, Fedora, etc.) all require ARMv7.

Fortunately the just released Pi 2 sports Cortex-A7 Cores which use the ARMv7 instruction set, which made this possible without any full rebuild.

Given that the only thing that has changed is the more powerful CPU, I'd say same fun and more interesting things! ;)

Nope, Ubuntu uses Unity, not GNOME 3.

Note that unfreed results of strdupa(), despite having "dup" in the name, does not result in memory leaks. The "a" in the name means it uses alloca(), thus the memory comes from the stack and it's properly released on function return. It's also probably slightly faster than malloc() since it just moves the stack pointer.

Before jumping to conclusions, please verify what the code really does. C is a complex beast and what's "obvious" may not be such.

Relying on such niceties (as weird as it may seem, to a C programmer those are niceties) is what you gain if you are willing to trade them for portability (strndupa() is a GNU extension).