Actually he successfully sued the tabloids for defamation on the grounds that while, yes he had a cosplaying dungeon, and yes the “attendees” were all in uniform, none of them were in Nazi uniform. To twist the knife he then went on to bankroll all the phone hacking civil cases against the same tabloids.
I moved from Proton to Fastmail (and Mullvad for VPN).
I was a a founding paying member of Proton Mail. I loved them and evangelised them for years. But after a decade, the quality of the offering, especially the mail and calendar, is almost a joke, and the company seems very distracted chasing the next big thing (the half baked password manager being one).
Comparing Fastmail’s UI and feature set with Proton, you quickly realise they are leagues apart.
And no Fastmail doesn’t provide e2e encryption. For that I use Signal, and for the few occasions where I need e2e encryption in email, I use PGP.
My only wish is that there was more client support for JMAP protocol. Even thunderbird doesn’t support it, and I can’t go back to IMAP because I like labels. Thankfully Fastmail’s own web interface is so good it is not a big issue.
I just did because of Quick Sync. Plenty of software has support for Quick Sync, the two I use are Plex and Immich. The AMD equivalent, VCN, has never had anywhere near the same level of software support.
For those curious about systemd-homed, lwn had a writeup about a discussion in Fedora about it which provides a good summary of the pros and cons of systemd-homed.
Meanwhile, I want to be able to mount my home directory on an external drive, and have it shared between systems without UID/GID hell.
And,
Have an encrypted home directory and boot the system and be able to enter my password with my keyboard which is connected to a thunderbolt dock during boot. Something which has been possible on Mac and windows for a decade or two.
Systemd-homed is the ONLY way to achieve these (and many others) in Linux.
Criticisms of systemd just because “it doesn’t smell like Unix” is all nice and fine, but ignores real quality of life and security features it provides. If you don’t have these usecases, you’re welcome to continue to ignore systemd, but some of us actually want these feature.
> Systemd-homed is the ONLY way to achieve these (and many others) in Linux.
It absolutely is not. [Full] disk encryption has been fine for... at least 15 years, probably more. Sharing a home directory requires consistent UID/GID, but that's not hard even fully manually (which is fine if you're just one person).
Yes Linux has had FDE on for a long time, but with traditional FDE using LUKS etc, you cannot use accessories such as a thunderbolt keyboard during the boot process to enter the password to unlock the disk.
Which is a problem if you’re like me and want to just connect your Linux laptop to a thunderbolt dock and use the keyboard attached to it.
You could have been a little clearer, but the main communication problem is that I didn't know that was a problem that could exist so it was easy to not follow. After a few minutes of confused web searching, I found https://fedoramagazine.org/thunderbolt-how-to-use-keyboard-d... which appears to describe the problem and some solutions (that don't involve homed, not least because this article predates it). AIUI, the problem is that you have to log in so you can approve the keyboard; that might be a pain point with an encrypted root (albeit it looks solvable), but if it works with homed I struggle to believe that it wouldn't work with any other encrypted home setup. Mostly because that part of homed is mostly a thin wrapper of code and convention over existing stuff.
No one is skeptical of compilers?! I guess you haven’t met many old fashioned C systems programmers, who go out of their way to disable compiler optimisations as much as they can because “it just produces garbage”.
Every generation, we seem to add a level of abstraction conceding because for most of us, it enhances productivity. And every generation, there is a crowd who rails against the new abstraction, mostly unaware of all of the levels of abstraction they already use in their coding.
Luxury! When I were a lad we didn't have them new fangled compilers, we wrote ASM by hand, because compilers cannot (and still to this day I think) optimise ASM as well as a human
Abstractions and compilers are deterministic, no matter if a neckbeard is cranky about the results. LLMs are not deterministic, they are a guessing game. An LLM is not an abstraction, it's a distraction. If you can't tell the difference, then maybe you should lay off the "AI" slop.
I've been thinking about this - you're right that LLMs are not going to be deterministic (AIUI) when it comes to producing code to solve a problem.
BUT neither are humans, if you give two different humans the same task, then, unless they copy one another, then you will get two different results.
Further, as those humans evolve through their career, the code that they produce will also change.
Now, I do want to point out that I'm very much still at the "LLMs are an aid, not the full answer.. yet" point, but a lot of the argument against them seems to be (rapidly) coming to the point where it's no longer valid (AI slop and all).
You keep making these claims as though you are some sort of authority, but nothing you have said has matched reality.
I mean full credit to you with your disingenuous goalpost shifting and appeals to authority, but reality has no time for you (and neither do I anymore).
I suppose a more rigorous definition would be useful. We can probably make it more narrow as time goes on
To me, the essence of coding is about using formal languages and definable state machines (i.e, your toolchain) to manipulate the state of a machine in a predictable way.
C, C++, even with their litany of undefined behavior, are still formal languages, and their compilers can still be predicted and understood (no matter how difficult that is). If the compiler does something unexpected, its because you, the programmer, lacked the knowledge of either the language or the compiler's state.
Vibe coding uses natural languages, and interacts with programs whose state is not only unknown, but unknowable. The machine, for the same input, may produce wildly different output. If the machine produces unexpected code, its not because of a lack of knowledge on the part of it programmer - its because the machine is inherently unpredictable and requires more prodding in soft, fuzzy, natural language.
Telling something what outcomes you want, even if described in technical terms only a programmer would understand, is not coding. It's essentially just being a project manager.
Now you may ask - who cares about this no true Scotsman fallacy? If its coding or not coding, we are still producing a program which serves the product needs of the customer.
Personally, I did not learn to code because I give a shit about the product needs of the customer, or the financial wellbeing of the business. I enjoy coding for its own sake - because it is fun to use systems of well defined rules to solve problems. Learning and using C++ is fun, for me; it seems every day i learn something new about the language and how the compiler behaves and I've been using C++ for several years (and I started learning it when I was 12!)
Describing the outcome or goal of a project in natural human language sounds like a nightmare, to be honest. I became a software engineer so I could minimize the amount of natural language required to succeed in life. Natural language has gotten me (and, I suspect, people like me) in trouble over and over again throughout adolescence, but I've never written a piece of code that was misunderstood or ambiguous enough for people to become threatened by or outraged by it.
I think the disconnect is that some people care about products, and some people care about code.
It's qualitatively different to go through source code and specifications to understand how something works than to look at a database with all the weights of an LLM and pretend like you could predict the output.
reply