801699

"... Google's AMP team even invited me to have lunch with them."

Reminds me of this: http://blackhat.com/media/bh-usa-97/blackhat-eetimes.html

As far as I can tell, in order to be "forced" on a user, AMP must rely on javascript, the browser used or maybe the OS (I trust they are not rewriting search results to point to AMP but that could be another one).

A no javascript command line tcp client will retrieve the page without automatically following the amphtml link. Users thus have a choice. And if choosing the amphtml link it is easy to filter out everything but the text of the page (the content). In that sense AMP is quite nice.

The "forced" nature of AMP should make users think about these points of control for advertisers and Google: javascript, browser, OS. Maybe website owners will think about them too the next time they "recommend" or "require" certain browsers. Web should be javascript, browser and OS neutral.

"But if being able to program means being able to write large programs..."

What does it mean when someone is only able (or only wants) to write small programs?

For example, small programs that can work together to form a "system" for managing something.

Is that not considered "software engineering"? If not, what is it called?

(Embedded software engineering? But not all small software is "embedded".)

What has a better chance of being error-free, a small program or a large one?

Should "ability to program" be measured by how large a program one can write?

For example, if someone writes a small UNIX utility, but does not write a large program, should we assume he does not know how to program?

in case not want to install tcl

https://github.com/drudru/pty4

http://empty.sourceforge.net

"... they're trending..."

they date back to the 80's.

to predict the future, some look to the past for ideas.

others monitor the present e.g. github commits for popular projects - reject anything that has no recent activity.

the context is per packet encryption, the space and time needed to do it.

this is not the approach taken by tls where one compromised packet can compromise the entire "encrypted stream". nor is the approach taken by dnssec where instead of encrypting some third party gives their blessing to (signs) the data being communicated.

elliptic curve crypto is not new. but encrypting each and every packet on the internet separately is "new" (or at least "different" from current practice).

this is my understanding. i could be wrong.

do not want to have it remotely configurable. nor want anyone to be able to "reset configuration" remotely.

some configuration is fixed, static. to change it one needs to change the image. this is intentional. hobbyist user wants this.

bootloader is on removable media user sends to provider. user is not using any provider software. user is paying for dedicated server and internet connection. that is all.

do not use linux, mirageos. do not need to. have rump. user can make own xen guest kernels and xen host kernels. anyway, this is tangent, irrelevant. user does not need virtualization necessarily and in any case not virtualization provided by third party.

simple requirements: want dedicated bare metal server. want hardware and internet connection. do not need/want provider software. will pay more for this.

so it is the scripting language used by ansible, chef, puppet that imposes the required "discipline"?

methinks each of these must in fact call the shell to get things done or least system(3).

if they are calling execve then i would be more interested.

i would also be interested in ansible, chef, puppet if i knew the scripting languages they are written in or wanted to learn them. but other languages interest me more.

as a hobbyist, what i would like to see is a hosting provider that will boot fs images (including bootloader) that user builds on users own computer. i.e., provider gives exact specs of machine and network details. user builds and sends fs image to provider and provider boots from it on some bare metal in a datacenter.

no "host" or "guest". no virtual server. no provider software. if something software-related does not work, it is user's responsibility because it is all user's software. user can send an updated fs image.

anyone know if this exists? the service wanted is barebones: a computer in a datacenter that has an internet connection and someone to boot it from user fs image. cost not an issue.

but he had assets there and his business required access to a us-based store.

one story said he met his wife in the us. if she was a us citizen that could be an addtional reason he might want to be able to travel to the us.

in other words, he had reasons to care about potentially having an outstanding judgment against him in the us.

or maybe the appeals court date was before he changed the name to pirate joes?

to be fair, i am making an assumption when i say he picked th wrong name (original name was transilvania trading): that he did not want to be sued in the us. but maybe he did. does not sound like he had a large legal budget though.

there is also the possibility that the name of the business and the other things he did to mimick trader joes had nothing to do with courts reasoning. the fact that he sold goods with a us trademark on the label was enough.

in that case maybe the name matters little.

but if that is true, then shouldn't we see some changes in the risk profile for all sellers of grey market goods even when the names of their stores bear no resemblance to any us trademark associated with goods they sell.

all of the grey market stores i have seen have names that do not mimick any trademarks held by the manufacturers of the goods they sell. but maybe i have not seen enough of them.

my opinion is he picked the wrong name. what consumer would think "transilvania trading" was an authorized reseller of trader joes? otoh, "pirate joes"? but what do i know? not much.

afaik, he was not sued in canada.

"I don't understand with what right..."

trademark. he picked the wrong name for his business.

companies that make the bios were* the other sources of "ultimate trust". why not let them...

*then came uefi.

hoop-jumping never a problem with the i.t. market. more complexity is fine so long as managed by someone else. only the sales pitch needs to be simple.

why is it unfathomable that users could only trust themselves and other users? continual push toward more complexity helps keep users from ever believing this is achievable.

company that sells ads says it will develop an ad blocker. why not stop selling ads as well? what is the goal?

I download static maps. I prefer maps as images or images in a PDF. But I understand your comment. Indeed it is the textual data that is at issue with respect to gratuitous javascript use.

A large amount of data maybe even the majority is already textual. For this data, from a user's persective there is no valid argument that "supporting" users who want to read text requires additonal work. Serving textual data certainly does not require javascript.

The "arrogance" if any is displyed by a website owner who for some unexplained reason does not want to let any users (e.g. 0.1%) read text without runing javascript. As if any user who does not care about whether the website makes use of the latest popular browser features is a user they do not want. But maybe that is not really the reason.

It is the last sentence in your comment that is the interesting one. Perhaps the use of javascript is designed to take something from the customer e.g. personal data via some discreet mechanism that requires running code on the user's computer. If this is true, then one might argue it becomes clear why website owners do not want users who do not use javascript. Because the website cannot take something from the user where the mechanism of extraction is powered by javascript.

If that is the case, it may inform the user about the website e.g. any website that tries to force users to use javascript may be one that is trying to extract something from the user. And as such may be a wesbite that the user should avoid.

As a sidenote, websites routinely serve content as text without the use of javascript because that is how they are most efficiently indexed by Google. Thus the website must "support" Googlebot. Some users may be quite satisified with the "Googlebot version" of the website.

https://github.com/anse1/firmforth

has not been mentioned on hn afaik.

i have seen hn commenters praise apple for "taking a stand on privacy". but how can anyone believe that when they collect so much personal data about the people who purchase their hardware? the old apple did not do this.

1. collecting data on users for months and years after purchase, 2. storing it electronically on remote computers, 3. some connected to the internet. yes, this surely points to a company is concerned about user privacy.

if something goes wrong can you sue apple?

we should expect every hardware vendor from laptop mfrs to the rpi foundation to be silently collecting data from their customers long after the merchandise is purchased. they need to do this, because...

wtf?

1. collecting data on consumers and 2. storing it online.

#1 is incompatible with a pro-consumer stance on user privacy.

#2 is a guarantee that others besides the company are going to get that data, whether the consumer is told about the breach or not.

the more reliant you become on popular corporate/"non-profit" controlled browsers the more disappointed you will be when the drm comes. but i will bet they will ease you into it to minimize the complaints. long ago someone predicted very early that the web would evolve into tv, driven by "pinheads". i believe he was correct.

anyone remember a browser from nocrew called zen? had framebuffer support. i think it also allows users to add new interfaces. still compiles cleanly today even on non-linux. code is in archive.org, see nocrew.org

have not tried to use it but am impressed that it is from 2004-ish and still compiles cleanly. framebuffer has had some significant improvements since 2004. could be time to revisit.

rdiff is free, open source and gives control to the user.

dropbox is large, binary-only, obfuscated code, built on FOSS (uses same library as rdiff), makes some people very wealthy and gives third party control over user's files.

i have never used dropbox. no need.

Here is something to use as a replacement for "grep -q".

In the past I found grep -q was not portable.

There are times when I do not have grep.

But I always have sed.

   cat grepq

   test $# -ge 1||
   exec echo usage: $0 PATTERN \[FILE\]

   # count lines until PATTERN 
   __=$(exec sed -n '/'"$1"'/!d;=;q' $2);
   # no of lines 
   exec test ${#__} -gt 0;

   grepq '93.184.216.34 example.com' /etc/hosts||
   echo 93.184.216.34 example.com >> /etc/hosts

Assuming some users know how to control a computer (some claim they do e.g. those working in IT), why would they tolerate this annoyance?

It must not be that bad or else they would work around it, using their professed skills in controlling computers.

Or maybe there are other reasons?

How many technical users are complaining about advertising while at the same time assisting advertisers to put their marketing cruft on the web?

http://startupclass.co/courses/how-to-start-a-startup/lectur...

This reasoning i.e. "supporting" people who are not using Javascript make little sense.

It is the Javascript and website complexity, the embellishment of data with needless garbage, that necessitates "support" i.e. work for developers. It creates more work.

Serving text without embellishment requires less work, not more.

At some time or place in every website development project, data exists in plain text or some other raw form.

Some users might just want that data as it is, without embellishment, before web developers even start working.

This requires little if any "web development" work. Basic HTML can be autogenerated with ease.

   <a href=http://example.com/data>Data</a><br>
   <pre>
    Description:  blah, blah, blah
   </pre>

     # usage: $0 section 
     # sections: world, etc. 
    curl -4o .$0  https://static01.nyt.com/services/json/sectionfronts/$1/index.jsonp
    exec sed '/\"guid\" :/!d;s/\",//;s/.*\"//' .$0

Meanwhile we are having this discussion on a web site that does more or less exactly what I am suggesting. It can be easily autogenerated. The HTML could have been written in the 1990's. It is trivial to remove the tags and have plain text.

I guess we are the 0.1% that would ever access a website that did not need Javascript?

The fact that the popular browsers run all manner of javascripts and process all sorts of tags does not obligate anyone to use them. Whether it is web developers or users.

There is a famed quote that goes something like this:

"An engineer is someone who can do with ten schillings what any fool could do with a pound."

By this definition one could argue Javascript developers are not engineers.

If the user can get the desired data from a website without having to run 4.5M of js in a large browser, but the developer "needs" 4.5M of js and a team of people to deliver the data, then who is the "engineer"?

Trivial to strip HTML tags and produce useful text.

Send all the extraneous garbage you want to the user. She can remove it and keep only what she wants. Meanwhile from the user's perspective you are wasting bandwidth. Who is paying for that bandwidth?

Is this really how developers think?

And what if the user does not download the .js file?

And what if the user downloads the .js file but does not run it in an interpreter?

What if the browser authors refuse to process what is enclosed in script tags and to run Javascript?

Maybe they believe it consumes too much memory.

Based on your comment (trolling?), I think maybe Javascript is not the problem. It is developers with thinking such as yours.

If we put inline js or links to .js files in files requested via HTTP, then we cannot claim that users "chose" or gave "permission" to fetch these .js files or to run them. As another commenter stated, those requests were not initiated by the user, but by the browser.

The selection of browsers is small, and made smaller by web developers who promote use of certain browsers i.e., big fat intepreters that will run their needless Javascript. (The keyword is "needless". Almost always users can get the data they seek without running Javascript.)

These "favored" browsers present a massive memory hog and attack surface compared to the minimal tcp client required to retrieve text via HTTP.