just_for_you
Wouldn't use raw GDI+ for any UI of moderate complexity, but it was perfect for the ghetto app I made myself.
Personally I'm glad that that the hyper-availability of information was something I experienced only after I became an adult, so I'm able to be more aware of how influential the firehouse of information and manipulation by algorithms can be.
One reason I'm stuck with Kindles is because Amazon makes it sane to look up words when reading Japanese books and articles.
When you use Amazon's "Send to my Kindle" service (eg, you email a book to yourself, and then it appears on your device), Amazon seems to do some kind of de-conjugation which magically knows how to break-apart terms and grammar so that you can easily look anything up. Normally, if uploading straight to your device, or if using a Kobo, a term you want to look up has to match your on-device dictionary exactly, which is clunky and awful, especially since Japanese doesn't use spaces and has lots of inflections.
If Kobo had something similar, I'd ditch using Kindles entirely.
Second time was from some new friends I had made, who argued that exchanging phone numbers and emails were old-fashioned and awkward when meeting new people, and that it was essential to have Facebook since it's easier to just say "you can just look for me on Facebook; you'll know it's me since I have XYZ in my profile pic". I saw some validity to the argument, since recently I had met and got along with a couple cute girls on a train ride, but regretted not exchanging contact details with the two of them because asking for numbers/emails felt like a slight overreach. Though if I had a FB account at the time, I thought it'd have made sense if I could've just been able to casually say something like "look up John Smith on FB if you wanna hang out sometime. See ya!".
Third time was my then-SO. She posted on Facebook a LOT, and had many hundreds of followers. She begged me to make an account for months, so I could bask in all the content she posted.
Anyway, your experience with people not using Facebook sounds on-par. Facebook is increasingly considered a "boomer" technology, especially by the younger generations. Many younger folk these days tend to keep in touch via small Discord groups, or whatever dopamine-drip privacy-nightmare app of the week is.
What turned me off from it was when I lost a year's worth of (unimportant) bookmarks and history. One day I opened it up and it decided to kindly sign me in automatically (probably detected I was signed into an MS site in-browser), and it wanted to automatically sync all my history, auto-fill info and passwords to Microsoft's sync servers. I immediately disconnected my account to stop this, and then it deleted my Edge profile afterwards as a further courtesy.
I understand that these two behaviors are probably Features, but I don't like the feeling of losing control of my software. And now these features like MSFT Rewards, coupon services, credit card services, and the "Bing Bar" (or whatever you call it) are just too much for me. Not to mention every PC I use Edge on tends to assault my eyes with political propaganda since Edge's New Tab page defaults to biased news outlets.
Like alcohol, drugs and smoking, endless streaming media is just something I don't touch. I know there's an insane amount of good content to watch out there, but I'm content with not knowing what it's like diving into that rabbit hole.
I've been railroaded into using Facebook 2 or 3 times by friends, family and even my SO, and my experience each and every time was a soulless one like yours. It was just a non-stop stream of people and their friends reposting shallow things they found on the Internet, inspirational quotes, and political garbage. And if people did comment, they were just brief quips - probably just enough effort to try to manipulate others to like+comment back on their own content.
Email and phone's all I need. If people can't put in the effort to remember or catch up with me, even if it's just every few months, then they're not my friend.
I was talking about Quarterly since it seems to the most stable way to get packages not in the base system.
pkg-ng is indeed a godsend, and I think I just got PTSD thinking about what Ports management was like before it. Currently getting flashbacks to the salad of utilities I used to use from ports-mgmt/.
>make
Yes, the Makefile infrastructure for both Ports/pkgsrc is clunky and slow, and the documentation is also terrible too. Took quite a bit of suffering to learn the dark art of properly authoring packages in pkgsrc.
For what it's worth, there's also the Gentoo Prefix project, but I haven't ever been able to use it because the bootstrap for it has failed every time I tried it on macOS or Linux.
At least for pkgsrc using it is as simple as: $ git clone https://github.com/netbsd/pkgsrc --depth 1 $ cd ~/pkgsrc/bootstrap && ./bootstrap --unprivileged $ cd ~/pkgsrc/misc/tmux && ~/pkg/bin/bmake install $ ~/pkg/bin/tmux
As flawed and janky as pkgsrc is, it has at least worked consistently for me on macOS/Linux for years.
>compiling from source
Yeah, I agree. Compiling everything from source and using it in production is for insane people. Should have clarified that when I said "Ports/pkgsrc", I meant using official binary pacakges, and not necessarily building from source.
>latest and quarterly
The point of quarterly releases is to serve as a base for stable package versions, backported security fixes, and as a chance to fix package runtime/compilation issues before being generally available - something harder to do if you track bleeding-edge packages, where things can shift under people's feet.
It's also useful when building from source, like I do with pkgsrc for macOS, because lots of random things will break if there's too large of a rift between what's installed and what's in bleeding-edge pkgsrc. In these cases, you'd usually have to do mass rebuilds, and/or deal with dependency hell (eg, pkg X you have installed needs need <=libsomething-1336, but pkg Y in pkgsrc needs >=libsomething-1337).
I use the packages installed via pkgsrc pretty much daily on my MacBook, and it'd be really annoying having things possibly breaking after an update just a week apart, especially if I'm in a rush and need to get something done for work. So using a quarterly branch is useful, since it's a cadence I can stomach, and there's a higher likelihood that the devs had more time to polish the packages in that release.
>Fink
Never heard of this before. I'll give it a gander sometime soon.
Same with systems like Ports, and in particular, NetBSD's pkgsrc. I've personally been using pkgsrc on my MacBook (and sometimes on Linux too) for years, and have really enjoyed using it as a cross-platform system to add my own little packages that'll work across macOS/Linux/NetBSD (I use NetBSD on my Pi). And I have no problems doing upgrades every 3 months, since I want my shiny new software.
So I definitely see and appreciate Ports/pkgsrc's benefits - but I still feel uneasy using stuff like FreeBSD+Ports on non-personal projects, like for projects at work.
https://wiki.freebsd.org/Ports/QuarterlyBranch https://pkg.freebsd.org/FreeBSD:13:amd64/ https://svnweb.freebsd.org/ports/branches/
That said, I don't have any problems with rolling-release. I've ran stuff like openSUSE Tumbleweed for years, and back in my dabbling days, plenty of Gentoo and Arch.
My issue is that for non-personal and longer-term deployments, FreeBSD has never been a contender for me because of having to keep on top of Ports upgrades. For example for a project at work, I wouldn't want to return to a FreeBSD deployment months later to add a feature, and then have to update all my packages on that system.
I understand chances are the upgrades would likely be hitch-free, or would only require a little bit of fixing around, but I still really don't want to hold my breath every 3 months.
For a home server I have no problem with this, but if it's something I want to leave in production and have security updates for, I'm more at-ease using Debian or Ubuntu with their 3- and 5-years' worth of support.
Is there something I'm missing about using FreeBSD in production, or is anything outside of the base system just supposed to be more hands-on?
I'd argue that's even worse than just using PSD by itself. If you open a PSD-inside-TIFF file in an image editor that doesn't recognize that PSD data or which discards unknown TIFF tags when saving, you'll end up having the PSD data getting stripped simply by saving.
Another problem is there might be a mismatch between the TIFF raster data and the embedded PSD document attached. For example someone could open the file in a PSD-unaware editor, make changes, and save the file only making changes to the TIFF raster data. Then later, when someone opens the file in Photshop, they won't see the changes because Photoshop ignored the newer TIFF raster data and used the older, embedded PSD document within it instead.
Anyway, it is indeed cool that you can encode JPEG-LS, Lossless JPEG and friends in the exact same format as you see baseline JPEG images in - but just in different application segments! (eg, baseline=SOF0/SOF1 segment, Lossless JPEG=SOF3, JPEG-LS=SOF48, etc.).
I also do appreciate MP3's simplicity, in the sense that it's just a series of concatenated frames. It makes it really easy to just fling them over the network and get streaming audio working on a client. And there's also somewhat of an elegance (a very ugly and hacky elegance, mind you) to being able to exploit decoders ignoring malformed frames.
For example if you open an MP3 IceCast stream via HTTP in a media player like VLC, the server (if it realizes, via the HTTP request headers, that you're Icecast-aware) will occasionally barf the name of the current and following song into the MP3 stream. Meaning you don't need any higher-level streaming protocol to deal with, and can just send raw frames over the wire, where the MP3 decoder will ignore the song title as a malformed MP3 frame, but VLC will pick-up on the song title and display it for you as the server cycles from one song to the next. Kinda handy, because VLC will make use of this metadata, but at the same time, the MP3 stream's URL will also work in a web browser too, since the browser won't need to know how to deal with a higher-level protocol before being able to start receiving those frames.
Actually, nevermind all that. MP3 bad.
1) If using 8 bits per pixel or less, there's always a color palette between the header and bitmap. If more than 8bpp, then there's none.
2) If more or equal to 8BPP, you must know that you must always use Bitfields to specify which bytes correspond to which RGB(A) channels, and that there cannot be any overlap between the channel masks.
3) There's no intuitive way to tell which version of the Bitmap file you have (there's like 5 major versions).
4) You can specify, inline, the Chromaticity and Gamma (basically an inline color profile) somewhere in the headers.
5) You can also append an ICC profile directly into the file, OR, store a Windows-style filesystem path to the profile (in which case, you must know to ignore the in-header color profile, if you have one).
6) You must know that RLE compression only works if the RGB channels cleanly map to one-byte-each (no packing).
7) RLE compression doesn't work if you use a negative height (to indicate the image is encoded from top-to-bottom, rather than the standard bottom-to-top).
8) The (un)official documentation Microsoft hosts states that BMP files can also store PNG or JPEG bitstream data, but yet no application that I've seen has ever explicitly supported this.
9) You have to know that Windows only supports 2 or so variations of packed 16-bit BMP files (565, etc).
For the most part you can just assume you're dealing with a v5 BMP file, read or write the most pertinent parts like the dimensions (skipping dumb stuff like ICC profiles, pixels-per-meter and whatnot), and just have your way with the raw data. But there is still some dumb stuff in there that shouldn't be there, considering it should be a straight-forward format. What also baffles me is that even with the bloat Microsoft added to the format, BMP isn't even extensible. So it's kinda the worst of both: It's slightly complicated to the point of not being straight-foward to work with, and yet, you can't add extra info/metadata to it.
On that note, Targa is a dreamy image format. It's got a simple 18-byte or so header, and then the raw data. And, optionally, for Targa v2 you can append a few bytes in a footer that indicate an offset for an optional standard-targa-metadata area, as well as an option metadata area for your data you wish to add to the file. Followed by a magic string, that explicitly indicate you're using v2 of the Targa spec.
It's possible that some of the other officially-defined segments (see https://exiftool.org/TagNames/JPEG.html) might also contain duplicate info, but then that'd be specific to the app that uses it, not for general-purpose use.
Storing the size in easily-parseable EXIF metadata and then once again in the JPEG bitstream seems pretty reasonable to me. Not to mention if you run a metadata/EXIF stripper on a JPEG file, then you remove all duplicate info and the only remaining image-dimensions will be stored in the JPEG bitstream anyway.
I can't do justice to the article on TIFF's problems with JPEG (http://www.simplesystems.org/libtiff/TIFFTechNote2.html), but my understanding is that:
1) Some JPEG-specific data is moved outside of the actual JPEG bitstream tag, and into separate TIFF tags, making editing JPEG-in-TIFF files non-trivial. 2) Size is not encoded in some of these fields, so the TIFF editor you're writing will have to partially implement a JPEG decoder just to know the size of some of those TIFF tags, and 3) Some tags/fields are pointers into other parts of the TIFF file, meaning if you edit the file, you'll have to update the file in many places.
(As a quick aside on insane formats, may I also mention the EPWING dictionary format?)
After a few hours, I was able to grok it without too much difficulty, and found the format was reasonably well laid-out. Yes, it does suffer from some "let's take the in-memory representation and bake it into the on-disk format"-isms, and there were a few things were not covered by the specification (eg, a couple Resource IDs aren't mentioned at all, or they are, but there's no documentation on how to interpret their content) - but it's not anywhere close to insane.
To give an example, partially going off memory from what I remember seeing in real files, but mostly skimming the spec, a very basic gist of a typical PSD files might look something like this. (I can only assume HN is going to mangle the formatting of the following text, so expect to see multiple edits to this comment):
EDIT: I was right about the formatting getting messed up. I've posted it to Pastebin and will call it a day:
https://pastebin.com/raw/WZNrCSAP
So that (the Pastebin link above) is the basic and oversimplified gist of a PSD file. It's mostly just reading 4-byte tags and length fields. Now, rendering a complex PSD file (or worse: generating a complex one) is another matter, but the on-disk format is pretty understandable IMO. Creating a bitmap-to-PSD conversion program from scratch is also something I could see being doable in a weekend if you followed the spec, and, as long as the PSD only contained simple rasterized data (eg, no filters and other fanciness) and only the bare-minimum ResourceID/Layer tags.
Honestly, I really trust PSD as a general interchange format for images. It's quirky in some places, but it's pretty logically laid-out, is universally-recognized, and I can rest assured that a rasterized copy of my images will always be stapled to the end of the file if worse comes to worse. There really is no alternative, because while you can contain Photoshop data in a format like TIFF (Photoshop just staples the entire PSD file into a TIFF/EXIF tag anyway), and if an application unaware of that PSD data opens the TIFF files and saves it, the Photoshop data might go poof or have a mismatch with the other TIFF data. And then there's Gimp's XCF format, where the on-disk format is allowed to be changed willy-nilly because you are only supposed to use Gimp's official library for reading/writing to it (not to mention no application really supports XCF aside from Gimp and maybe a few open-source projects). And let's not even bother with $application-specific formats, because they are meant only for that specific application.
The moral of the story is PSD is an alright format.
I've tested comparing Gnome/KDE on old hardware (eg, 2 GB of RAM and CPUs built for power conservation), and subjectively I found KDE to be a lot snappier (Gnome Shell always choked for me when hitting Activities) and, after a few hours of uptime, found it used less memory than Gnome. On the same box, it even gave Xfce a run for its money, which was surprising.
Although, when it comes to peddling Linux to other people, I'm hesistant to install KDE for anyone because it's a bit too configurable. I'm always afraid of getting asked for help because of someone accidentally messed up their UI and losing their taskbar or something like that. KDE's came a long way in recent years, but that "you can configure everything" core will always probably be there. And on the flip-side, if I install Gnome, people often find it outlandish and barebones...
I have nothing against KDE by any means (I love it, and also really appreciate their initatives like KDEnlive, etc.), but I don't think I've ever gotten Japanese/Chinese input to work in it before. Maybe once, but then I gave up on finding a sane way to easily cycle between the different input types (eg, WinKey+Space).
https://github.com/google/brunsli
I personally use the cbrunsli/dbrunsli cmdline programs to archive old high-resolution JPEG photos that I've taken over the years. Having a gander at one subdirectory with 94 photos @ 354 MB in size, running cbrunsli on them brings the size down to 282 MB, which brings in savings of about 20%. And if I ever wanted to convert them back to JPEG, each file would be bit-identical to the originals.
Perhaps it's a little early to trust my data to JPEG XL/Brunsli, but I've ran tests comparing hundreds of MD5 checksums of JPEG files losslessly recreated by Brunsli, and have not yet ran into a single mismatch.
I can only say that I am very excited for the day that JPEG XL truly hits primetime.
And in general, things that are made to work well together work better than things not made to work well together. This also applies to things that happen to work well together, despite not initially being designed to.