TheLoneWolfling

I will not rent anything that can be copied losslessly. (Among other things, this is the major reason I don't have netflix.) And I consider anything that can be (legally) taken from me without my consent, or that I cannot legally reencode, to be rented.

"Buying" an ebook currently is effectively renting it. If/when that changes, if/when I can actually buy an ebook, I will start buying ebooks.

Nevertheless, writing (essentially) append-only files is something that happens often enough that most filesystems should cope with reasonably well. And writing 20x slower than it could is nowhere near coping reasonably well.

(Also: note that you don't need to cope with nfs/etc. Flash is different enough from spinning rust that I have no problem with a filesystem being optimized for one or the other as opposed to both.)

Potentially, although in that case it's still dsyslog's fault.

PDFs are about the worst thing out there if you're frustrated about documents with embedded Turing-complete languages.

And large bitmaps are rather bandwidth inefficient, and inaccessible to boot.

I don't mind markup. I mind tech that doesn't include fallbacks, and I mind people using Turing-complete languages for things that can easily be done using a less powerful language. (Turing-complete languages tend to get abused by people to the point that people want them to be executed quickly and with little memory use (which means that the language implementation gets complex, and hence buggy {simple laws of probability}), and almost any vulnerability can generally be exploited by a suitable script in a TC language, and TC-languages can be used to do unexpected things.)

HTML is decent. HTML+CSS is worse than HTML (for the same reason that COMEFROM is worse than GOTO). Markup is better than HTML in many ways, or rather most formal specifications of Markup-like languages are better than HTML. (Unfortunately, most variants of Markup aren't specified beyond "do what I do")

I've been tempted for a while to write a Markup browser. (Mop? Markup-Over-tcP? )

Let me make the connection a little more explicit:

In {the burger case}, {removing sesame seeds} is an act that makes {the product} objectively worse, just in a way that will hopefully not make it worse enough to affect demand.

And in {this case}, {punting things from server-side to client-side} is an act that makes {power usage, wear and tear, security, battery life, bandwidth use} objectively worse, just in a way that will hopefully not make it worse enough to affect demand.

In which case, what on Earth is rsyslog doing that it takes 1ms to append a line of text to the log file?

I could see it if it was outputting something to software-based video - except that in that case, why is it trying to output to software-based video?

I was speaking in the context of with JS disabled.

There's a JS-based fade-in on page load (or at least there was; the author mentioned that it'd be changed at some point) that doesn't bother to have a fallback. And as such there's a CSS rule that sets the post opacity to zero (making it unreadable).

There are many many many websites that don't work without JS that work if you disable both JS and CSS. This being one of them.

That being said, even other than that there are a number of things I don't like about the website. All personal preference, however. (Namely: 85-85-85 font on 255-255-255 background isn't the best, contrast-wise (I have a laptop and am often outside - readability trumps fashion for me); I don't like the trend of narrower and narrower line widths (It looks bad enough on my laptop, on a 2k screen 700px width would just look ridiculous); Ditto, I don't like the trend of higher and higher line heights - 1.2 is plenty, 1.5 is overkill, this site is 1.7; Continuing on the trend of "why do you put so little on the screen", I find the paragraph separation also overkill (1 line between paragraphs or equivalent is fine, and maybe two between sections)))

Good theory. Alas, the author mentioned it took ~1ms, which would be ~11.5 characters, and those log messages are a lot longer than 11.5 characters.

Let me tell you a (probably-apocryphal) story:

There was a giant multinational hamburger chain where some bright MBA figured out that eliminating just three sesame seeds from a sesame-seed bun would be completely unnoticeable by anyone yet would save the company $126,000 per year. So they do it, and time passes, and another bushy-tailed MBA comes along, and does another study, and concludes that removing another five sesame seeds wouldn't hurt either, and would save even more money, and so on and so forth, every year or two, the new management trainee looking for ways to save money proposes removing a sesame seed or two, until eventually, they're shipping hamburger buns with exactly three sesame seeds artfully arranged in a triangle, and nobody buys their hamburgers any more.

(http://www.joelonsoftware.com/items/2007/09/11.html)

Completely sidestepping the question of if the grandparent comment is correct, they are trying to imply that YouTube shouldn't be trusted.

Thank you kindly!

And again, the fade-in (although I don't like said effects personally) isn't the problem. The problem is that said fade-in is done via JS with no fallback. (Note that you can generally do fade-ins via CSS, IIRC, or just add a noscript tag that overrides it to full opacity)

I suspect that there is other functionality that I'm missing without JS (No sidebar? Buttons to the side that do nothing?), but it's kind of hard to tell.

Except that it's relatively simple to make an append-only file both quick to write and reliable on flash...

It seems that both the file system and flash controller punt the relatively common (and relatively simple) case of a file being repeatedly appended to by small amounts.

> Adobe has made the file format available on the web

Good for them. Nonetheless, my point stands. In many places, it is illegal to reverse-engineer file formats, and in many places it isn't illegal but may as well be due to the potential costs of determining that it is legal.

(For instance, "The information in this document is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Adobe Systems Incorporated. ". What happens if/when they pull said document?)

(Also: note that them documenting their file format is not the same thing as there being no potential liability for anyone to use said info.)

This is where you benefit by having a file system (or disk controller) that isn't brain-dead.

Unfortunately, it seems like both the controller and file system are brain-dead on the RPi.

Namely, you have a cache that detects this sort of (relatively-common) append-only operation, and buffers it until it makes sense to actually write it (either because the disk is otherwise unoccupied or because you are close to the limits of your power buffer).

Alternatively, you have a file system that actually knows the advantages and limitations of flash. You can do append-only files efficiently on flash (without doing all of the read + write dance). "All" you need to do is take advantage of a bit of scratch space and knowing how flash works. Namely that you don't necessarily need to flash a block to write to it, as long as you are only turning zeros to ones (or vice versa, depending on how physical bits are mapped to logical bits. Multilevel flash is a little more complex, but still doable). (For instance, instead of having one filestamp, you have space for 16 filestamps, with two bytes at the beginning, all initially set to all zeros. You check the last bit set and use that filestamp. Congratulations, you now can update the file 16 times before needing to reflash the block. If that's not enough, you can extend it arbitrarily (note that you can do this dynamically for files only when they are updated enough to warrant it!) And metadata/etc can be done in the same way. For something like a log file, you have, say, 16 slots for how much of the block is occupied, and a pointer to the next block (or null). You append the content of the new log line to the file and add the new content. One write, no blocks being flashed. (Two writes if/when you run out of space in the block.)

See, for instance, https://github.com/bnahill/FLogFS/ or https://en.wikipedia.org/wiki/F2FS/

> Nowaday’s fast Class 10 cards achieve their high read and write speeds only by buffering in advance, assuming that the subsequent blocks will be read or written next. That means they inevitably sacrifice random read and write speeds. This effect is in the order of several magnitudes. For instance, a card with sequential read and write speeds of 10 MB/s might collapse to just 0.01 MB/s for random access.

Yow. Yet another example of over-optimization to benchmarks.

...Except that, even then, how exactly is appending to a log file repeatedly random access? Bad journaling?

Better yet: a file the decompresses to multiple slightly different versions of itself. Say, one that is a version of itself with an additional one, and one that is a version of itself with an additional zero.

Here's a fascinating thought.

It should be possible to write an archive file that decompresses to a slightly different archive file. Say, the original archive file plus a zero byte. (Things get hairy because of the checksum in most archive file formats, but it still should be possible.)

Then a malicious party writes an archive file that decompresses to two slightly different archive files. And sets it up so that, say, 128 levels in iff you follow a specific path in said tree you get to the actual malicious content. You can't get to it unless you follow the specific path, and you can't find it unless you do substantially more than just naively decompressing files (as you won't be able to decompress 2129-1 files).

A common misconception.

There is no universal compression algorithm, by the pigeonhole principle.

And your compression scheme won't work by the simple fact that the offset of where in Pi your data lies will, on average, take the same number of bits to store as the data itself. Ditto, with pi to the power of lots of random numbers, the offset and the power will, on average, take the same number of bits to store as the data itself.

What happened to the free market is that it isn't (a free market). It's illegal in many places to reverse-engineer the .psd file format - and there are many places where even if it's not illegal the potential lawyer costs are so prohibitive that it may as well be.

Tangentially related: What is the smallest self-hosted interpreter? What about the most efficient one?

This isn't it (among other things, it isn't self-hosted).

Don't forget the Pi (generally) uses flash. So seek speeds are irrelevant.

If you're writing the following in 1ms:

    Apr  4 22:50:59 heating kernel: [14572.940927] Unhandled prefetch abort: breakpoint debug exception (0x002) at 0x00008438

By my count that's ~1 kilobit.

That means that you're writing to flash at ~1 Mb/s. (~125KB/s) That's slow, to put it mildly. (~5% of what it should be, according to http://ozzmaker.com/2012/12/27/how-to-test-the-sd-card-speed... ) I could see that kind of speed if it was causing a disk seek every write (although if it was doing that you're probably using the wrong file system), but again, the Pi uses flash.

So what gives? Is there braindead sync behavior that's causing it? Is it hitting a pathological case in the flash controller? Or what?

(For that matter: is there a file system that is optimized for log files?)

And then someone prevents you from running said oven until you pay them a ransom.

(Or just starts turning on peoples irons at random, if it can turn them on as well)

I personally think the security implications outweigh the potential benefits for most IoT devices. It's too bad, because the potential benefits are generally nice.

(And the other side is: I have no desire to "buy" a device that can have features remotely removed. It's why I ditched Windows, it's why I won't ever buy a Tesla or an iPhone, it's why I don't have any recent game consoles. And most IoT devices fall into this category. Among other reasons, it creates a perverse incentive for a company to break (intentionally or unintentionally) older models (or allow them to fall into disrepair) so that people will upgrade to this year's model.)

Perhaps a better quote would be "People don't want to buy a quarter-inch drill. They want (a) quarter-inch hole(s)!"

Wait... It takes ~1ms to write a line to a log file?

Agreed.

As I said: it's a trivial fix.

I find it rather... ironic, shall I say, when CSS actively hurts the readability of a site.

This being one of those cases.

For me, the utility of reading some random blog post that requires JS is far less than the potential consequences of enabling JS for every random blog post, given that most browser exploits require JS.

As such, when the only reason that a site requires JS to be readable is sloppy coding, yes, I call them out on it.

I enable JS only for things that require it for a good reason, and where I am reasonably sure that they won't be exploited. Doing a fancy fade-in on load (which, by the way, can easily be done accessibly) is not a good reason, and I am not reasonably sure that some random blog won't be exploited.

Sidestepping the question of if that actually adds anything to the article - they couldn't be bothered to do the fade-in correctly?

It's not mine - it's from http://tantek.com/2015/069/t1/js-dr-javascript-required-dead

Complex software is possible to get right in the same sense that it is possible for all the O2 molecules in this room to move to the other side of this room at the same time.

It is technically possible, but improbable enough that, in the absence of direct evidence to the contrary (in this case, a functional browser that doesn't have bunches and bunches of exploitable bugs in its JS engine), it may as well not be.