I agree. I feel they are doing it more for aesthetics than actual 'energy' consumption, but then they must justify why they are dithering, and "because it looks pretty" doesn't fit their shtick.
Even if it did save bandwidth, that does not equal significant energy savings. And if it did, there are better ways to save.
For example, looking at their response headers I see the image cache control expires after a day, plus has validation caching. This could be significantly improved. First, get rid of the `etag`, `expires`, and `last-modified` headers and go with expiration caching only. Increase the `max-age` from one day (86400) to one year (31536000). I get the HTML expiring after 24 hours, but images should be more aggressively cached. Validation caching always requires a round trip to the server, plus running validation rules on every single request so it can't save nearly as much bandwith and CPU as simple expiration caching.
Also, if they got rid of the those headers, plus the pointless `server: nginx/1.10.3` they could save over 100b per HTTP response. I counted 19 requests on that article, so it may seem small, but it can add up to a significant amount.
> First, get rid of the `etag`, `expires`, and `last-modified` headers and go with expiration caching only. Increase the `max-age` from one day (86400) to one year (31536000).
Since it's a statically generated website, I'd favor never expiring the cache, and using cache-busting hashes instead. That way the cache is only emptied when the file actually changes.
It can be, but doesn't need to be as long as it is some sort of indication of the uniqueness of the content. A last modified date should work in the same way.
Hi I'm one of the people that worked on the webdesign, back-end and hardware. You are right about the caching, one of our strategies is actually to cache very aggressively. Not only for images but even for all HTML aside from the front page and about pages. This works for us since low-tech magazine only publishes a maximum of one article a month and the site spans a decade of content which won't change anymore.
However, since we were still working on the site at the time it got massively popular, we changed the caching settings in order for people to see the changes and fixes that we were pushing.
Cool, that makes sense. You should be able to easily turn off etags in your nginx config. This won't just save bytes in your response headers, but will stop a lot of HEAD requests to your server that are required to do validation caching.
If you look at the non-solarpowered website, it turns out that TypeKit is serving a 830,8 KiB fullcolour PNG file. AAARGH. No wonder that they think they need to use dithering and such if that is their baseline.
I tried testing some variants and made a static HTML gallery on neocieties[1]. TL;DR:
- cleaning up the photo before filtering it makes a huge difference in image quality and compression.
- quality 80 JPG is 86,6KiB in color, 70,9Kib in grayscale.
- quality 40 (which is ugly but still has readable text) uses 44,8KiB and 37,8Kib respectively. The latter looks a lot better than the dithered image IMO.
- similarly, the grayscale PNG with pushed shadows and positioned dithering has readable text and contains significantly more detail at 4 colors and 38,7KiB than the 16-color 42,4KiB image on their server.
The dithering on images is actually kinda nice. Less visual over-stimulation.
But whatever this site is doing with the fixed-scroll yellow block is super weird. There's a "95%" thing next to a sun - is it somehow related to the solar battery powering the server?
Rather than focusing on the content, the design focuses on the infrastructure at the expense of the content. Maybe that's the point, but this particular element is certainly off-putting.
I feel that the focus on infrastructure _is_ the content. It may be over the top (dithering is especially BS), but without battery indicator how many people would discover that the server runs on sustainable solar power?
Before starting to read the article, I tried clicking and dragging on that element and searched the page for "brightness" and "dim" before peeking at the source to realize it isn't a brightness control after all.
Well OK, this makes me wonder: if it truly is a static site, how are they injecting all this dynamic data? Or are they just faking it by re-generating the site periodically?
It's obviously subjective, but I really like the yellow-ish block background for the battery level. Lends the site a distinctive paper-like feel that reminds me of the Financial Times.
> The main challenge was to reduce page size without making the website less attractive. Because images take up most of the bandwidth, it would be easy to obtain very small page sizes and lower energy use by eliminating images, reducing their number, or making them much smaller. However, visuals are an important part of Low-tech Magazine’s appeal, and the website would not be the same without them.
I agree with you on the yellow background battery meter, but not the dithered images. At desktop sizes, it reminds me of the low-res dithered hell of the 90s, except its worse because it's effectively yellowscale. I hate image dithering with a burning passion. I bet the same images would look better as low res JPEGs (they are currently PNGs, which are made less compressible with the dithering noise).
It might be annoying if you're really trying to get a good look at something, but I think it is kind of a neat aesthetic. Some of the old PC-Engine/whatever dithered art looks great.
Yeah, as a random viewer, I really only need to know that the power is running out when the last bit of charge is nearly used up, at like 5% maybe.
I have no concept of whether even 10% means another hour or another year, and since it's load dependent, neither do they. If the power is at 75%, what do I care?
It really belongs on a status page, and as a banner, pinned to the top of the page. If anything, it motivates random people to slam the page with more hits, just so they can watch the meter move.
That was my second impression, once I realized what it was. I wanted to watch for a chnage. My first impression was that the styles were defective, it was a scripting error (until I read that extra fluff was eschewed) or whatever, but I just wanted to find a way to make it get out of the way, so I could read without the distraction, so I started looking for "dismiss" icons, to close a broken pop-up.
Then I noticed the Sun icon and the percentage, and realized it was a meter.
Neat article, but I think we should distinguish basically two things here that the article blurs together:
1) Reducing website bandwidth and computational usage (static sites, small images, reducing extra resource requests). Super common topic that HN talks about all the time.
2) Reducing the electricity bill for the server and powering it with renewable resources. This part is quite neat, I think, but for a single bespoke website, the energy savings of using a single low-power server seems pretty trivial in the grand scheme of things — I could get similar savings by changing a living room lamp to a more energy efficient bulb.
This inspires me to propose a third category of energy efficiency that the article doesn't touch on: human energy costs.
Humans are quite energy intensive devices, and I suspect that the labor and human-maintenance costs of making this website dwarf the direct energy costs of running a webserver. I'd be curious how one would go about optimizing these other energy costs, and whether that can be done in a way that still preserves quality of work/life for the humans involved.
Is that a comment on the effort to produce a site like this, or the cheapness of energy and bandwidth?
The effort required to produce a site like this would be negligible, given that it's almost entirely plain HTML. Dithering the images would take seconds in something like GIMP. The HTML looks to have been produced by a tool, based on the formatting, so they wouldn't need to spend time working with markup.
What about the energy used to design and build the infrastructure? There's a lot more that went into this project than just the static site, which is something the article touches on.
To illustrate, I'm going to invent some numbers:
Let's say that this site on "standard" hardware would use 1kW per day. This means the existing site saves ~950W per day looking at just the hardware energy use.
However, the hardware it's running on had to be produced, let's say that costs 10kW. The solar panels and batteries need power to make, let's; say they cost another 30kW of power.
Additionally, the system needs to be designed and built by a human being. Humans use a lot of energy. Let's say that this took 1 week to design and build. Let's say a human "uses" 50kW of "power" per day (e.g. from food production, etc.). This means it costs an additional 350kW of power to design and build the infrastructure.
Adding up all these made up numbers gives us a total infrastructure cost of 390kW. This means that, in order to "pay back" the difference, the new system has to operate for (390,000 W / 950 W/d =) 410 days.
These numbers are wildly inaccurate and cut a lot of corners, but this should give an idea as to what the grandparent was getting at.
Sidenote: I'm not, personally, trying to make a point about the project itself. Just, in order to fully understand the energy impact you have, you need to take a lot more into account than just "the amount of work performed by the computer".
On topic 1 I was thinking to myself the other day, "I wonder if I can create a static webpage that isn't some sort of SPA or web app."
It took me time to work out where to start... Once you think it through you realise it is pretty easy and obvious. But (and this gives away my age a bit), I have not built a static webpage since school (over 10 years ago), and have become so accustomed to all the crazy shit that goes into web development today like Webpack, NPM, React, Angular etc etc that I had forgotten how to actually just serve a piece of HTML.
My dependence on all these frameworks and CLIs sent me on a quest to find out more about pure javascript, and I came across an incredible talk by a developer who created a pure javascript web app for music notation. I really wanted to link it here but cannot find it.
I have found that static generators, specifically Hugo, have made just plain HTML fun again. They give you just enough power to not repeat yourself endlessly (e.g. maintaining each page and copy-pasta all changes between them) without turning into the system's we're all trying to step back from.
The odd thing about this to me is that I feel just throwing those few MB of static files on a CDN would actually be more energy efficient. There is a great deal of energy needed to create and distribute a raspberry pi, and there is basically no energy needed to add a few files to servers that are already up and running constantly.
The dithering is nice for some images but it takes some details on graphs etc..
The example image given can be re-compressed using techniques like structural similarity (SSIM)[1] or Multi-scale structural similarity (2003 Paper)[2]. Using jpeg-archive[3] I resized the example image from the blog[4] with decent results:
If I understand you correctly, you propose a image format which should provide a better quality for less file size. However, to implement an in-browser client-side reader, one probably needs a javascript library, and this will blow up the size again [Side note: Actually I am surprised the site uses JavaScript at all, being that static].
To implement the improvements you suggest on this site (which appears to be a static site), the best way would be to have your proposed image compression as part of the static site preprocessor, correct? Just trying to understand how it would be implemented, as this site is an interesting idea but the dithered images would likely not have mass-appeal.
Yes, you'd just run all of the images through jpeg-recompress (from the GitHub repo linked above). They're already doing something like this to dither, so it's just a question of swapping out which command to run.
Incidentally, even where PNG is appropriate (images with crisp edges, such as text and icons) you can frequently get a large size savings by applying zopflipng, which uses an alternative GZIP compression algorithm to get a higher-efficiency compression, at the cost of greater CPU use for encoding.[1]
I think this is a really cool idea actually. I help run a fair few websites for authors/creators that don't need 5 digits of up-time and super heavy websites. I'm sure most blogs/sites would be fine being much much lighter and running off something like this.
Using a datacentre such as S3 will gain the benefits of an economy of scale. Per-website S3 energy costs are going to be substantially lower than the energy cost of a solar-server: each solar-server that is installed will have had to have been built in factories which cost energy to run, shipped in delivery vehicles which cost energy to drive, plus the humans behind the website would require energy while building the server... all of which would easily be more than the net energy consumption of a single website in S3.
That being said, the point of the project is to produce a website that is 100% solar powered. They never said they were aiming for something that is feasibly sustainable.
It would be nice if there was a site that indexed RSS feeds that contain whole articles, not just ledes and snippets meant to get you to click into ad-riddled articles.
For some reason Firefox is only showing the <summary> contents when you click that link, but it's all in there and it shows the full article in ttrss for me.
Seems to have links to, and 1-sentence descriptions of, all of their articles.
This isn't very useful if you want your RSS reader to pull down articles for you to read while you're offline. For that to work, you want the feed itself to have the full text of every article embedded inside it.
I agree, but I would also expect to only receive text data and not images (or very highly compressed images). The other part of keeping the bandwidth cost of an RSS feed down is keeping a smaller number of articles in "rotation".
EDIT: I just pulled their RSS feed - 50 articles currently in rotation! 32.42kB according to FireFox of just snippets of text and links!
Dithered images do not compress well. I'd be interested to see side-by-side comparisons of optimised pngs, optimised jpeg, reduced-pallete optimised pngs, and some more cutting-edge formats like BPG[0] and FLIF[1]
That does somewhat depend on whether we are talking about positioned or Floyd-Steinberg dithering. Positioned dithering is a lot more regular and predictable, and hence easier to compress.
I once basically did just that, besides the image dithering. I ran a small blog off a Raspberry Pi, only using Markdown files and something to render them to HTML. I used my own IP address, which I know you're not technically supposed to do but in 15 years I've never had an ISP crack down on me for it, and had a script that would run periodically to update the A record for my domain in Route 53. (since my IP was dynamic)
Whether you're doing it for energy purposes or not, it's a fun project because it feels a bit like sticking it to the man, since we're used to always hosting our sites on someone else's machine.
My guess is that this is mostly a way for them to object if you start using too much bandwidth. Most ISP's "guarantee" way more bandwidth than they can actually provide on a daily basis. If you're hosting a website that gets low traffic, normally, they probably will not only not know, but not care. Just my guess.
For several years starting in 2010 I ran my personal website off a Pentium III Thinkpad running Plan 9 sitting on the floor behind my desk. I wrote the web server in Go; it was a "hybrid" in that it served mostly static files, but in the blog subdirectory it would render Markdown to HTML.
It worked great! I eventually migrated to a VPS when the hardware started to get too flaky with age (and years of accumulated dust sucked through the fan inlet)
Small sub-cultures, like this one, do experiments all the time in their little corner of the web. Some of the cultures die after a while, and some grow into something else, something bigger, something that starts to percolate on the mainstream surface, albeit possibly only tangental to how it started. I'm not sure I'd predict this movement will grow into something that reaches mainstream tech, but let's say I'm wrong, just for fun. Can anyone here think of a potential narrative that would describe how the current state of this experiment could possibly be perturbed and squeezed into a form that the mainstream soaks up as the next big (or medium-sized) thing?
I'm just curious to know how my prediction that this won't grow any larger than it is today could be wrong.
While unlikely, I could see more wide-spread adoption of this concept if a large online company began using the approach. If Twitter for example decided to cut out all their bloat, simplify served graphics and assets, and invest in sustainable energy, I could see other high-profile internet companies following their lead.
Could well not happen, but the most likely driver of slimmed down websites, anyway, would be a desire to make them load better in India, Africa, parts of Latin America and eastern Asia that have low connection speeds. Not saying that's how it will go, but it's feasible that to get to the second and third billion internet users, you need to be slimmer.
It's still kind of a niche, though. People who don't live where decent internet access is readily available also tend to not have enough disposable wealth to make great business targets, especially for social media and other sites that sell eyeballs rather than widgets.
On the other hand, one of the first things people with disposable income want today is good internet access, so as income grows for the middle five billion (and it's growing rapidly), there's tremendous market pressure to supply them with faster internet - maybe not up to the standards of the top billion, but not "low tech" either.
(In this case, the tangible benefits are highly debatable, especially since we moved on from CRT monitors - although I'd be interested to see data from OLED displays)
See "brutalist" websites. At the start it was very similar in spirit with this website: raw, functional, rejecting looks for something you appreciate in a different way. Now: ugly, full of js, heavy.
"Less than 100% reliability is essential for the sustainability of an off-the-grid solar system."
IMO, this can only become mainstream once there is no longer an expectation of "100%" uptime for websites in general.
It's far-fetched, but I can imagine it becoming mainstream if mesh networking becomes popular, or if the Internet were to become a widely self-hosted platform (e.g. people had their own "clouds" running in their homes). In such situations, 100% uptime would no longer be an expectation, so the perceived cost of using an off-the-grid system would be reduced.
Having been in the “mesh” space for years, there’s a ton of this techno-primitivism fantasy floating around. The reality is that people want to access the internet and they want it to work well.
This article is a perfect example. This solar powered server which does not have 100% uptime for artistic reasons is probably sitting in someone’s kitchen next to a refrigerator which uses many times as much power and definitely has 100% uptime.
> refrigerator which uses many times as much power and definitely has 100% uptime.
Except that the making-cold mechanism of fridges have nowhere near a 100% duty-cycle. You probably wouldn't notice if it didn't even meet two "nines" of uptime.
In fact, that's how frost-free freezers work, by taking advantage that fact to run a heater(!) for some number of minutes several times a day. A defrost timer that does 10 minutes every 8 hours reduces compressor uptime to 98%.
You'd be able to get to normal levels of uptime by putting backup solar servers in e.g. the Sahara and northern Australia, then taking them out of your DNS rotation when they dropped below 5% battery, surely.
Though transmitting data that far might be against the point of the art project.
I think it will more likely come when the true cost of high energy consumption is factored into our decisions, and people are forced to trade off high availability for low power consumption.
if it ends up being very easy to run a solar powered website- i.e. if it turns out the process can be refined and simplified nicely- then lots of places would do it since its cheaper and cool. but im sure lots of typical business constraints (uptime for instance) would dictate that lots of companies will never do it.
It seems to me that it would eventually be possible, to build a relatively cheap system that can both soak up power and transmit/recieve data without any external wiring.
You could hook up a raspberry pi to a solar system, weatherproof it, then deploy it in the wild. Add a wireless "router" of some sort, and then you have a mobile broadcasting station.
Imagine a world where such systems are very cheap to build. Also -- imagine that they could be "networked" if they are in range. Finally, imagine hobbyists building out that network for fun. Maybe in neighborhoods, public parks, etc.
Imagine the technology greatly improves and gets even cheaper. These are plastered everywhere, by everyone. They can transmit and receive data very quickly, over reasonably far distances.
Maybe it becomes an off-grid anarchist internet. :)
Can anyone here think of [...]
how [...] this experiment
could [be] squeezed into
a form [...] as the next
big [...] thing?
This is definitely firmly in the "Internet of Things" genre of niche interests. Remote power monitoring and other system diagnostics for systems designed to account for expected faults, and manage their own capacity to operate, for sure are useful for internet managed consumer appliances.
Right now we only think in terms of wi-fi routers and phones, but when 4 out of 5 useless gadgets (oh boy! internet-enabled shampoo bottles that also can advertise hair gel! yaayy!) have a battery and 5G internet, an RSS/JSON/XML feed of their status will be abundantly relevant.
To... someone. Probably not me, but I'm sure someone will want this.
well, if the sub-culture takes off among young people then it could supplant selfies as the means by which people broadcast what they are doing 'right now' ... interestingly that would drive down interest in going viral as a sudden spike in visitors could kill someone's site until the next day
Wonder if they've considered a gravity battery? As an additional benefit it'd let someone local "recharge" the battery manually rather than being 100% tied to the Sun.
My suggestion is to get a larger solar panel. Solar is cheap now, less than US$1 per watt. Why not get a 100W or a 200W panel? It will put out enough power to supply the server and router on a rainy day. The battery will only be necessary overnight.
The price of 18650's is low enough that building your own pack to handle 30W continuous overnight is not costly. To help with the environmental impact and cost you can get used batteries that are being recycled or thrown away.
> The size of the average web page (defined as the average page size of the 500,000 most popular domains) increased from 0.45 megabytes (MB) in 2010 to 1.7 megabytes in June 2018.
It's the second place I see such low average size values (I'd say, somewhat reasonable), but I'm having a hard time believing in them. On a typical site, when I hit F12 and proceed to Network tab, I usually see ten times greater values. I fear that those statistics are either undercounting something, or 500k is just so many domains that the long tail of lightweight sites drags the average down, making values not representative of the real situation. I wonder how those stats would look if the average was weighted by the number of visits.
There is also the issue that caching (e.g. cdn of jQuery or React libraries) can mean that, if you visit a given website every day in a month, you may only download that library once (the first time). Their estimate is definitely lowball for your first visit, but it might be a reasonable estimate for how much is actually downloaded on average.
I remember from over a decade ago there was an annual contest to make the best web page that would fit into 5KB - yes, 5000 bytes. There were many impressive entries.
I'd really hoped it would catch on.
Sadly, that lightweight concept is now so forgotten that I can't even find it in a quick search. (perhaps someone else can find a pointer?)
This should be an obvious choice for sites not requiring dynamic elements. Also their choice of comments through email is a good solution to a problem static-made blogs have.
>Dithered Images
That won't work for every case, but is interesting.
>Default typeface
That's nice. I'm already disallowing sites to choose their own typeface. Except if a site is about design, then the typeface doesn't matter and probably I won't prefer their choice over mine.
>No Third-Party Tracking
This makes sense and I don't understand why self-hosted sites are doing it. The logs are there. Analyzing them is all that is needed.
>No Advertising Services
I'm fine with that but some sites rely on ads. I ain't aware of a method that will keep with their goals and provide ads.
You don't need a thirds party tracker to get fancy graphs. Matomo is free, open source, self-hosted, works on logs, and has fancy graphs. An ELK stack would also work fine.
Lazy-loaded 1px images can be used for tracking how far users have read and a/b testing can be done by compiling multiple versions and redirecting users to the version you want them to try.
If I could toot my own horn for a moment, Gravwell (gravwell.io) has a 2GB/day free license which should be plenty to ingest web logs. We've got a GeoIP module to resolve IPs to locations, we can display geographic heatmaps (see https://dev.gravwell.io/docs/#!search/map/map.md), a variety of charts, tables, etc.
Matomo looks really polished and if it provides the features you need, it seems like an obvious choice. If OTOH you're looking at rolling your own with ELK, Gravwell might make sense.
> This should be an obvious choice for sites not requiring dynamic elements. Also their choice of comments through email is a good solution to a problem static-made blogs have.
This is one I find interesting. I doubt they want to manually go through every email. So some semi-automation sounds sensible too. What would be an elegant solution to that?
It's a good start, but the CSS is obnoxious and definitely not low-tech, and the image dithering is a bad compromise between having real images and simply not having images at all. In short, it's an attempt at a low-tech website made by people who've never seen a real low-tech website, and probably wouldn't know Lynx if they saw it in use.
Doesn't this seem a bit uncharitable a characterization? What's an example of a "real low-tech website" that does better than the work presented here? Are you browsing hackernews using lynx or surfraw?
According to the article, the goal here was to demonstrate the possibility of making an attractive, modern-looking Web page while still having it be lightweight. Your example does not achieve the first goal at all.
187 comments
[ 14.7 ms ] story [ 3878 ms ] threadIf you take this[0] image, it's 43 KB for a 800x533 image. I'd expect a JPEG to be able to do that without too much in the way of artifacts.
It does give the page a kind of neat newspapery vibe, though.
[0]: https://solar.lowtechmagazine.com/dithers/sps_wide.png
[0]: https://bitsquirrel.co.uk/800x533.jpg
I do agree that the consistency is nice for aesthetic reasons, but poorly rendered images do detract from the overall message.
For example, looking at their response headers I see the image cache control expires after a day, plus has validation caching. This could be significantly improved. First, get rid of the `etag`, `expires`, and `last-modified` headers and go with expiration caching only. Increase the `max-age` from one day (86400) to one year (31536000). I get the HTML expiring after 24 hours, but images should be more aggressively cached. Validation caching always requires a round trip to the server, plus running validation rules on every single request so it can't save nearly as much bandwith and CPU as simple expiration caching.
Also, if they got rid of the those headers, plus the pointless `server: nginx/1.10.3` they could save over 100b per HTTP response. I counted 19 requests on that article, so it may seem small, but it can add up to a significant amount.
Since it's a statically generated website, I'd favor never expiring the cache, and using cache-busting hashes instead. That way the cache is only emptied when the file actually changes.
However, since we were still working on the site at the time it got massively popular, we changed the caching settings in order for people to see the changes and fixes that we were pushing.
I'll look into those server headers as well!
I tried testing some variants and made a static HTML gallery on neocieties[1]. TL;DR:
- cleaning up the photo before filtering it makes a huge difference in image quality and compression.
- quality 80 JPG is 86,6KiB in color, 70,9Kib in grayscale.
- quality 40 (which is ugly but still has readable text) uses 44,8KiB and 37,8Kib respectively. The latter looks a lot better than the dithered image IMO.
- similarly, the grayscale PNG with pushed shadows and positioned dithering has readable text and contains significantly more detail at 4 colors and 38,7KiB than the 16-color 42,4KiB image on their server.
[0] http://www.lowtechmagazine.com/2018/09/how-to-build-a-lowtec...
[1] https://blindedcyclops.neocities.org/low-tech-image-tests/ga...
[0]: http://www.lowtechmagazine.com/2018/09/how-to-build-a-lowtec...
But whatever this site is doing with the fixed-scroll yellow block is super weird. There's a "95%" thing next to a sun - is it somehow related to the solar battery powering the server?
Rather than focusing on the content, the design focuses on the infrastructure at the expense of the content. Maybe that's the point, but this particular element is certainly off-putting.
edit: nvm, just found the javascript that rejiggers the DOM based on data from https://solar.lowtechmagazine.com/api/stats.json
The site was 95% solar, but the blue bar at the top was 100% distracting. I could barely read the content.
Yes, but does it also consume less power, formatting the images this way?
I have no concept of whether even 10% means another hour or another year, and since it's load dependent, neither do they. If the power is at 75%, what do I care?
It really belongs on a status page, and as a banner, pinned to the top of the page. If anything, it motivates random people to slam the page with more hits, just so they can watch the meter move.
That was my second impression, once I realized what it was. I wanted to watch for a chnage. My first impression was that the styles were defective, it was a scripting error (until I read that extra fluff was eschewed) or whatever, but I just wanted to find a way to make it get out of the way, so I could read without the distraction, so I started looking for "dismiss" icons, to close a broken pop-up.
Then I noticed the Sun icon and the percentage, and realized it was a meter.
1) Reducing website bandwidth and computational usage (static sites, small images, reducing extra resource requests). Super common topic that HN talks about all the time.
2) Reducing the electricity bill for the server and powering it with renewable resources. This part is quite neat, I think, but for a single bespoke website, the energy savings of using a single low-power server seems pretty trivial in the grand scheme of things — I could get similar savings by changing a living room lamp to a more energy efficient bulb.
This inspires me to propose a third category of energy efficiency that the article doesn't touch on: human energy costs.
Humans are quite energy intensive devices, and I suspect that the labor and human-maintenance costs of making this website dwarf the direct energy costs of running a webserver. I'd be curious how one would go about optimizing these other energy costs, and whether that can be done in a way that still preserves quality of work/life for the humans involved.
The effort required to produce a site like this would be negligible, given that it's almost entirely plain HTML. Dithering the images would take seconds in something like GIMP. The HTML looks to have been produced by a tool, based on the formatting, so they wouldn't need to spend time working with markup.
To illustrate, I'm going to invent some numbers:
Let's say that this site on "standard" hardware would use 1kW per day. This means the existing site saves ~950W per day looking at just the hardware energy use.
However, the hardware it's running on had to be produced, let's say that costs 10kW. The solar panels and batteries need power to make, let's; say they cost another 30kW of power.
Additionally, the system needs to be designed and built by a human being. Humans use a lot of energy. Let's say that this took 1 week to design and build. Let's say a human "uses" 50kW of "power" per day (e.g. from food production, etc.). This means it costs an additional 350kW of power to design and build the infrastructure.
Adding up all these made up numbers gives us a total infrastructure cost of 390kW. This means that, in order to "pay back" the difference, the new system has to operate for (390,000 W / 950 W/d =) 410 days.
These numbers are wildly inaccurate and cut a lot of corners, but this should give an idea as to what the grandparent was getting at.
Sidenote: I'm not, personally, trying to make a point about the project itself. Just, in order to fully understand the energy impact you have, you need to take a lot more into account than just "the amount of work performed by the computer".
It took me time to work out where to start... Once you think it through you realise it is pretty easy and obvious. But (and this gives away my age a bit), I have not built a static webpage since school (over 10 years ago), and have become so accustomed to all the crazy shit that goes into web development today like Webpack, NPM, React, Angular etc etc that I had forgotten how to actually just serve a piece of HTML.
My dependence on all these frameworks and CLIs sent me on a quest to find out more about pure javascript, and I came across an incredible talk by a developer who created a pure javascript web app for music notation. I really wanted to link it here but cannot find it.
I have found that static generators, specifically Hugo, have made just plain HTML fun again. They give you just enough power to not repeat yourself endlessly (e.g. maintaining each page and copy-pasta all changes between them) without turning into the system's we're all trying to step back from.
Neocities? It's where I occasionally dump my static-can't-be-bothered sketches.
http://neocities.org/
The example image given can be re-compressed using techniques like structural similarity (SSIM)[1] or Multi-scale structural similarity (2003 Paper)[2]. Using jpeg-archive[3] I resized the example image from the blog[4] with decent results:
[1] https://en.wikipedia.org/wiki/Structural_similarity[2] https://ece.uwaterloo.ca/~z70wang/publications/msssim.pdf
[3] https://github.com/danielgtaylor/jpeg-archive
[4] http://krisdedecker.typepad.com/.a/6a00e0099229e88833022ad3b...
Another proposal for image compression is to fall back on SVG, c.f. https://jmperezperez.com/svg-placeholders/ -- at least this does not need JS.
Incidentally, even where PNG is appropriate (images with crisp edges, such as text and icons) you can frequently get a large size savings by applying zopflipng, which uses an alternative GZIP compression algorithm to get a higher-efficiency compression, at the cost of greater CPU use for encoding.[1]
[1]: https://blog.codinghorror.com/zopfli-optimization-literally-...
That being said, the point of the project is to produce a website that is 100% solar powered. They never said they were aiming for something that is feasibly sustainable.
^ seems to have full articles.
This isn't very useful if you want your RSS reader to pull down articles for you to read while you're offline. For that to work, you want the feed itself to have the full text of every article embedded inside it.
EDIT: I just pulled their RSS feed - 50 articles currently in rotation! 32.42kB according to FireFox of just snippets of text and links!
[0] https://bellard.org/bpg/ [1] https://flif.info/
That does somewhat depend on whether we are talking about positioned or Floyd-Steinberg dithering. Positioned dithering is a lot more regular and predictable, and hence easier to compress.
https://after-dark.habd.as
Whether you're doing it for energy purposes or not, it's a fun project because it feels a bit like sticking it to the man, since we're used to always hosting our sites on someone else's machine.
It worked great! I eventually migrated to a VPS when the hardware started to get too flaky with age (and years of accumulated dust sucked through the fan inlet)
I will build your static html page for money. Hit me up. ;)
I don't have a cellphone myself, so i never tested it.
I'm just saying the low tech and mobile compatibility aren't mutually exclusive.
I'm just curious to know how my prediction that this won't grow any larger than it is today could be wrong.
Just my 2¢
I can see more wide spread adoption when people pay 2/mo for twitter and 3/mo for facebook.
On the other hand, one of the first things people with disposable income want today is good internet access, so as income grows for the middle five billion (and it's growing rapidly), there's tremendous market pressure to supply them with faster internet - maybe not up to the standards of the top billion, but not "low tech" either.
1. If there was a way to show others:"i'm saving energy while browsing the web"
2. People using those sites could use this as a tool for telling themselves a story about themselves
3. site builders would choose this from similar reasons
Maybe the user community that will form around this will be interesting, so it would be worthwhile to join, for the sake of people and content.
http://www.blackle.com/
(In this case, the tangible benefits are highly debatable, especially since we moved on from CRT monitors - although I'd be interested to see data from OLED displays)
1.4MB (most are thumbnails) and kept to stock bootstrap 3
"Less than 100% reliability is essential for the sustainability of an off-the-grid solar system."
IMO, this can only become mainstream once there is no longer an expectation of "100%" uptime for websites in general.
It's far-fetched, but I can imagine it becoming mainstream if mesh networking becomes popular, or if the Internet were to become a widely self-hosted platform (e.g. people had their own "clouds" running in their homes). In such situations, 100% uptime would no longer be an expectation, so the perceived cost of using an off-the-grid system would be reduced.
This article is a perfect example. This solar powered server which does not have 100% uptime for artistic reasons is probably sitting in someone’s kitchen next to a refrigerator which uses many times as much power and definitely has 100% uptime.
Except that the making-cold mechanism of fridges have nowhere near a 100% duty-cycle. You probably wouldn't notice if it didn't even meet two "nines" of uptime.
In fact, that's how frost-free freezers work, by taking advantage that fact to run a heater(!) for some number of minutes several times a day. A defrost timer that does 10 minutes every 8 hours reduces compressor uptime to 98%.
The solar webserver is another step towards that goal.
Though transmitting data that far might be against the point of the art project.
I welcome that day.
You could hook up a raspberry pi to a solar system, weatherproof it, then deploy it in the wild. Add a wireless "router" of some sort, and then you have a mobile broadcasting station.
Imagine a world where such systems are very cheap to build. Also -- imagine that they could be "networked" if they are in range. Finally, imagine hobbyists building out that network for fun. Maybe in neighborhoods, public parks, etc.
Imagine the technology greatly improves and gets even cheaper. These are plastered everywhere, by everyone. They can transmit and receive data very quickly, over reasonably far distances.
Maybe it becomes an off-grid anarchist internet. :)
https://en.wikipedia.org/wiki/2007_Boston_Mooninite_panic
Right now we only think in terms of wi-fi routers and phones, but when 4 out of 5 useless gadgets (oh boy! internet-enabled shampoo bottles that also can advertise hair gel! yaayy!) have a battery and 5G internet, an RSS/JSON/XML feed of their status will be abundantly relevant.
To... someone. Probably not me, but I'm sure someone will want this.
From there you can heavily reduce the color count and select the dithering type.
My suggestion is to get a larger solar panel. Solar is cheap now, less than US$1 per watt. Why not get a 100W or a 200W panel? It will put out enough power to supply the server and router on a rainy day. The battery will only be necessary overnight.
The price of 18650's is low enough that building your own pack to handle 30W continuous overnight is not costly. To help with the environmental impact and cost you can get used batteries that are being recycled or thrown away.
It's the second place I see such low average size values (I'd say, somewhat reasonable), but I'm having a hard time believing in them. On a typical site, when I hit F12 and proceed to Network tab, I usually see ten times greater values. I fear that those statistics are either undercounting something, or 500k is just so many domains that the long tail of lightweight sites drags the average down, making values not representative of the real situation. I wonder how those stats would look if the average was weighted by the number of visits.
I'd really hoped it would catch on.
Sadly, that lightweight concept is now so forgotten that I can't even find it in a quick search. (perhaps someone else can find a pointer?)
Seems I'd misremembered it as being more recent than in was, last one in 2002. They apparently 'grew' to 10K, and that site is now 404 also.
At this point, 50K would be a welcome respite from the mountains of cruft that download with every click...
>Static Site
This should be an obvious choice for sites not requiring dynamic elements. Also their choice of comments through email is a good solution to a problem static-made blogs have.
>Dithered Images
That won't work for every case, but is interesting.
>Default typeface
That's nice. I'm already disallowing sites to choose their own typeface. Except if a site is about design, then the typeface doesn't matter and probably I won't prefer their choice over mine.
>No Third-Party Tracking
This makes sense and I don't understand why self-hosted sites are doing it. The logs are there. Analyzing them is all that is needed.
>No Advertising Services
I'm fine with that but some sites rely on ads. I ain't aware of a method that will keep with their goals and provide ads.
1) Laziness. A third-party JS tracker usually comes with a complete dashboard, full of pretty (and sometimes even useful) graphs.
2) Data. Client-side trackers can spy on users more, giving you more information you can e.g. missapply in an A/B test trying to drive "engagement".
RE 1, there exist tools aimed at analyzing server logs. I played with GoAccess a bit, it's quite OK. https://goaccess.io/
Lazy-loaded 1px images can be used for tracking how far users have read and a/b testing can be done by compiling multiple versions and redirecting users to the version you want them to try.
Matomo looks really polished and if it provides the features you need, it seems like an obvious choice. If OTOH you're looking at rolling your own with ELK, Gravwell might make sense.
This is one I find interesting. I doubt they want to manually go through every email. So some semi-automation sounds sensible too. What would be an elegant solution to that?
That's a low-tech website. Absolutely nothing but content.
The design team of solar.lowtechmagazine.com is squarely on the side of the bettermotherfuckingwebsite.com
Authors probably deploy by pushing to a git repo or ssh-ing into the server.