bct

I'm agreeing with you.

> The only truly secure way to record messages up to the point of break-in is a one-way remote log.

And if you have this then you don't need a fancy cryptographic syslogd to detect tampering.

Annoying people is easy, I don't know why he would go out of his way to do it. It's certainly not something to be proud of.

Only a select few can implement specific DRM modules, but nobody is talking about standardizing them.

The standard (that is being proposed) in this case is an interface that the actual DRM modules hook into. Anyone can implement the interface.

If "standards compliant" means implementing every feature then no new (or existing) browser will ever be standards complaint anyways. This is not a lever that can be used to force everyone to implement DRM.

I'm glad you did (but I wouldn't have finished if you hadn't).

More people learning & having fun is better. IMO people only complain about the extended deadline because of its effect on the rankings.

The scoring system was an interesting addition over CTF2, but it also created these complaints and silliness like people submitting the same code repeatedly to get the best score possible.

It may have been better to only tell players what broad percentile group they're in. There would still be an incentive to write faster code, without the frustration of being edged out of position #20 because someone else's submission was (arbitrarily) scored a few points higher.

The problem description did say:

    # Our test cases will always use the same dictionary file (with SHA1
    # 6b898d7c48630be05b72b3ae07c5be6617f90d8e).

> we should have perspective on its inexorable march.

There is no such thing. There are only specific technologies. Some march inexorably, some are jokes (if they're remembered at all).

"And when you pray, do not be like the hypocrites, for they love to pray standing in the synagogues and on the street corners to be seen by others. Truly I tell you, they have received their reward in full. But when you pray, go into your room and close the door."

And `git checkout -p` too.

An example: webkitgtk requires (IIRC) 16GB of memory for the final link step if you turn on debugging.

quannabe: You have been hellbanned since your second comment.

> Just adopt the best of those

You say that like everyone agrees on what "the best" is.

Basically, but it also handles some details specific to the websockets protocol.

That's an issue with this implementation, not the idea of hooking up stdin/stdout to websockets.

spacebe4time: You have been hellbanned for several months.

The intent is simple, but there are many ways to express that intent. Some of them work well when there are two components sitting right next to each other in memory on one machine; others work well for an unknown number of components interacting with each other over a slow, unreliable network.

Even if RPC is a fundamentally, unambiguously simpler way to express that intent (and I think that's arguable), it does not meet the same technical requirements that REST does.

> If you're lucky it will be 'article'. But you probably won't be.

This situation can be improved (and is being improved). If we treat HTML as nothing but a display language, then it will become one - and if that's what you want, then you should just be using PDF, PNG or SWF.

> And it will remain this way because HTML isn't intended the way you seem to think it is.

I guess we've reached the root of our disagreement. It's exactly how it was intended to be used historically, it's how it is still used for the most part (with webapps being a notable exception), and I think it's the best way to use it going forward.

> The HTML you get when you go to a web page is anything but an abstraction of a data type.

You don't think that "this is an article", "this is a paragraph", "this is a link", "this text should be emphasized" are abstractions? And how is Markdown different, when it describes exactly the same elements of a document?

> now we're back to telling the whole web how to make web pages.

Telling people how to make web pages isn't a problem - that's what the HTML standard is. Depending on the whole web to make their pages suit your individual needs is a problem.

> You may not even need the API if the CMS doesn't screw around too much with the presentation by putting, say, ads, in the middle of the content.

This is exactly what I'm saying.

> Then you could screen scrape and convert the generated HTML back into Markdown,

Why do you want the Markdown at all?

alphadogg, you have been hellbanned for more than 2 years.

I'm familiar with the distinction between document and data. I'm talking about a site like a blog, where the document is the data. That was the original context of this conversation, IIRC.

HTML is emphatically not a poor document format, but it satisfies different requirements than PDF and RTF do. The weak connection between structure and what you call "style" (what I would call presentation) is a feature; it allows clients to modify the presentation to suit their needs. If I want a bigger font or higher contrast or a smaller column width, I'm able to do that because of the separation between structure and style.

But (as you rightly pointed out) this is a lot harder than it should be (and harder than it used to be). As a result, when an HTML document doesn't work for someone (due to its presentation) they have to complain to document creators instead of merely configuring their client (once) to suit their needs. This sucks.

> So why on earth would you use that very bad library design

Because when you design a Web API you're not designing a library, you're designing part of a distributed system.

Accessing code on a remote server is not like accessing code in a DLL, and never will be.

> You don't store data as HTML

You do if your data is a document.

And after CSS was introduced, HTML was definitely not supposed to be presentational.

> easily get the content you need in JSON format or similar

When user stylesheets were conceived this is what HTML was.

You don't need responsive CSS, all you need is max-width.

The (technically) ideal place to solve this is in your browser's user stylesheets (then you can have the page look however you like!), but that's a bad solution right now for obvious reasons (how many people even know that they exist?).

tomaszkubacki: You have been hellbanned.

The obvious next question is "can't you achieve the same thing with gzip":

    time curl http://code.jquery.com/jquery-2.0.3.js > /dev/null
    236k bytes
    real	0m0.432s

    time curl http://code.jquery.com/jquery-2.0.3.min.js > /dev/null
    83612 bytes
    real	0m0.323s

    time curl http://code.jquery.com/jquery-2.0.3.js --compressed > /dev/null
    87509 bytes
    real	0m0.273s

    time curl http://code.jquery.com/jquery-2.0.3.min.js --compressed > /dev/null
    34066 bytes
    real	0m0.215s

I think that people should be more skeptical of the complexity introduced by things like minification, but the advantages are pretty clear, even with compression.

It feels exactly the same arguing from the other side. I think that means we're working with fundamentally different premises.

Back in the old days (2005) we used to call this Do the Simplest Thing That Could Possibly Work.