Location: Bogotá, Colombia
Remote: Yes
Willing to relocate: No
Technologies: HTML, CSS, JavaScript, SVG, TeX/ConTeXt, PHP, Jekyll, Tailwind CSS
Portfolio: https://miler.codeberg.page/
Résumé-CV: https://codeberg.org/miler/curriculum-vitae/raw/branch/main/curriculum-en.pdf
Email: Please see Portfolio or CV/Résumé
GitHub: https://github.com/acidrums4/
Professional graphic designer with experience in both frontend and backend web development (PHP; Wordpress, Framer, some Joomla and some Typo3), iconography, editorial design/typesetting with ConTeXt and general graphic design. Please feel free to check my portfolio for some examples of my work.
One day when I have some extra bucks I'd try to get a home server running, but the idea of having something eating grid electricity 24/7 doesn't seem to play along well with this 3rd world budget. Are there some foolproof and not so costly off-grid/solar setups to look at (like a Raspberry-based thingy or similar)?
Your fridge and other home appliances likely use much more power than whatever a small server would. The mini PC in the article is very power efficient. You likely won't notice it in your power bill, regardless of your budget. You could go with a solar-powered setup if you prefer, but IMO for this type of use case it would be overengineering.
Only thing is you can't run Proxmox which makes self hosting much better, and you'll be limited to ARM builds, which on server is at least a lot easier than trying to run desktop apps. Modern micro desktops are also fairly power efficient, perhaps not quite as low as the mac, but much lower than a regular gaming desktop idling.
Avoid stacking in too many hard drives since each one uses almost as much power as the desktop does at idle.
Sure, but later in the article it says that when PHP came out it solved the problem of not being able to do includes. Which again... server-side includes predate PHP. I think that this is just an error in the article any way you slice it. I assume it was just an oversight, as the author has been around long enough that he almost certainly knows about SSI.
I have no idea when Apache first supported SSI , but personally I never knew it existed until years after PHP became popular.
I would guess , assuming that `Options +Includes` cannot be done by unprincipled users, that this being a disabled-by-default feature it was inaccessible to majority of us.
I have also dug around a bit to find out this one, and the earliest httpd I could get my hands on is 1.3.0 which is hosted on the Apache archive site: https://archive.apache.org/dist/httpd/
"src/modules/standard/mod_include.c" says:
/*
* http_include.c: Handles the server-parsed HTML documents
*
* Original by Rob McCool; substantial fixups by David Robinson;
* incorporated into the Apache module framework by rst.
*
*/
Rob McCool is the author of NCSA HTTPd so it seems there is direct lineage wrt. this feature between the two server implementations.
Archive.org tells me I was using SSI in Jan 1997. I didn’t really understand what I was doing, but including the footer and a visitor counter via an exec one which I presumably copied from somewhere else. At the time I was still on windows and had no real concept of a program being executed as a cgi or ssi, it was all “copy this from Matt’s script archive to your cgi-bin directory”
My shared hosting from claranet supported ssi via a .htaccess configuration.
Technically php was around at that point, but I don’t think it became popular until php3 - certainly my hosting provider didn’t support it until then.
The article mentions that in the very next sentence
> You either copied and pasted your header into every single HTML file (and god help you if you needed to change it), or you used <iframe> to embed shared elements. Neither option was great.
If they insist on only using vanilla HTML then the problem is unsolved to this day. I think it is actually less solved now, since back then HTML was an SGML application, so you could supply another DTD and have macro-expansion on the client.
Does it really? I think, this makes you have a wrapper and I am not sure if you can get rid of all issues with "display: contents". Also you are already in the body, so you can't change the head, which makes it useless for the most idiomatic usecase for that feature.
Yes it is, but since "KDE 5" I've seen less of it. Besides the obvious example of Konqueror another great example of it was reKonq, which used Akregator, Okular and Kget to handle RSS and PDFs respectively (all within the reKonq window).
Just from the top of my head that I've noticed as a user: several apps, such as Dolphin or Yakuake, use konsolepart; KWrite uses katepart, and Ark uses various parts in its file preview.
[0] https://dosaygo-studio.github.io/hn-front-page-2035/news-hon...
reply