Tue, 14 Jul 2015
Which Web Gallery?
I am looking for the best way how to publish my photos on the Web. So far I have ruled out putting my photos to some "cloud" service out of my control (Picasa, Flickr, Rajče). I want something which could generate a static tree of files (HTML/CSS/JPG/JS), which can then be published by any web hosting service, or even on my own server.
Some time ago I have tested Highslide.js, but this is more lightbox than a gallery, and it cannot adapt itself to the size of the screen.
What looks promising so far, is the thing named Photoswipe. There still are some problems, though:
- When the image has much wider aspect ratio than the screen, the image caption is displayed far away from the image itself.
- The thumbnail view somewhat sucks (see the thumbnail lists near the bottom of their own getting started page.
So, my dear lazyweb: which gallery for static files do you use? I would like to have something with the following properties:
- Works on different screen sizes (even Picasa sucks at this).
- Easy to generate all the data from large JPEGs with comments/title.
- The ability to link individual images (Highslide sucks at this).
What would you recommend?
5 replies for this story:
Vašek Stodůlka wrote:
I know, that it is maybe something different, then you are searching, but I'm using trovebox. You can see it live at fotky.stodulkovi.cz. It supports private and public stuff, sharing by creating link, albums, tags (!) and is quite fast. What is bad is, that trovebox is discontinued, but it is still by far the best private-hosted gallery I have seen, and I have searched a lot. (I had to do also some tweaks to have it working the way I want to.)
Yenya wrote: Re: Vašek Stodůlka
Apparently your trovebox requires cookies or whatever - I was not able to make it display any photo at all - just the surrounding text and an empty page.
Vašek Stodůlka wrote:
Hm, you are right with cookies, I have never tried this. :-) There is session ID cookie. IMHO there is nothing wrong on cookies, as long as they are used by the server, which originally issued them. BTW - Picasa works without cookies?
Yenya wrote: Re: Picasa
Picasa without cookies? No idea, I don't use Picasa. And for things like Google Excel (or whatever, people occasionally send me links to that crap and want me to write something in there) I tend to have a special Firefox session which has cookies for TheBigBrother.com allowed.
Michal wrote: JAlbum
How about JAlbum?
Reply to this story:
Mon, 13 Jul 2015
Systemd Developer Attitude
Systemd. Some people love it, some people hate it. My own position is somewhere in between: I think many things they are trying to solve are real problems which need solutions, the system should "just work" for common use without the configuration, etc. But sometimes the overall attitude of the systemd developers is just plain wrong. The following bug report shows the problem pretty clearly:
TL;DR: it can be summarized as follows:
systemd-timeduses Google time servers by default.
- These time servers are sometimes wrong because of the non-standard "leap second smearing" done by Google.
- Google has asked that their servers are not set up as defaults in
There are several solutions to this problem which I would consider clean and fair:
- Remove the default time servers from the configuration, let the user decide (e.g. to use a NTP pool).
- Register a NTP pool vendor zone and use it as defaults.
- Let somebody else register and maintain a NTP pool vendor zone (CoreOS people offered to do this).
The systemd maintainer's response was "we are not a vendor, we don't want a vendor pool", and "let's add a warning when somebody uses the defaults". I think using Google servers against the will of their owner is pretty rude, and having the defaults which need to be replaced, even though the possibility of having sane defaults exists, to be inconsiderate to their users.
In my opinion, the above clearly shows the attitude of systemd developers towards the rest of the world.
0 replies for this story:
Reply to this story:
Fri, 10 Jul 2015
My First CVE Number
After banging our collective heads against the wall while trying to discover why one Samba share works as we expect, while another one with the same configuration on the same server does not, I have finally admitted that the bug is not in our setup, but probably in Samba itself.
Interestingly enough, the expected behaviour was the share where it did not work, and the other one worked only by accident. The fact that it worked in one case turned out to be a potential minor security issue. So this is the first security issue I have discovered, which has its own CVE number: CVE-2015-3287 (details will be in Samba bug #11395 after it is declassifiled).
I appreciate the fast response of Samba developer Jeremy Allison: the first fix was available within 3.5 hours after the bug was reported.
1 replies for this story:
Peter Kruty wrote:
3,5h,that pretty fast. Nice.